Creating useful Pacman hooks

Can you use $USER in a hook? They don't get executed by root?

1 Like

$USER is a bit dynamic.
You can check yourself
sudo echo $USER
will still give you the normal username from the account executing sudo.
if you su into root then echo $USER it will return root.

What I use in some places is
YOU=$(who -am | awk '{print $1}')

[ie - execute who -am | awk '{print $1}' .. that should work in all the ways.]

Isn't that because $USER is being interpreted by the shell before the call to sudo?

If you did

sudo bash -c 'echo $USER'

It will return root because it doesn't interpret $USER until bash is run.

I was curious so I created a hook to test it and here is the output:

:: Processing package changes...
(1/1) removing kwrite                                                                                                                                                                      
:: Running post-transaction hooks...
(1/4) Checking user
user is root
(2/4) Updating icon theme caches...
(3/4) Arming ConditionNeedsUpdate...
(4/4) Updating the desktop file MIME type cache...

Ah. Fair. If/then strikes again!

I get confused with the results of using $USER, because if you write a system service $USER usually defaults to root. Yet, I wrote a user service a couple of days ago and launching the script with $USER was fine, but the actual Python script would not accept the arguments using $USER.

Considering I don't feel like testing everything for everyone, I think it's just simpler sometimes to add the disclaimer to change it to your own user name.

At least that way people might realize what the problem is when testing something new if it's not working. It's kind of like using ~/ for home. Sometimes it works, sometimes it doesn't, and sometimes new users have no idea what the ~/stands for.

1 Like

For some time I've been using one that jonathon provided a while back (slightly modified). (No :crossed_swords: here. :grinning: just though you might be interested...)

1 Like

if we have some user for same manjaro, we have several backups in several directories ! or we can use pacman in chroot
Not sure with pamac : pamac have its own environment ($USER not exists)

best ? is to pass "user" (or directory) in hook

Exec = /etc/pacman.d/hooks.bin/ toto # or /run/media/toto
find /run/media/${user}/*/ ...
1 Like

Thank you again @papajoke I updated my script to replace "$USER" as per your suggestion. You have other timeshift script customizations to limit triggering excessive backups as well (don't you)?

Do you think your script could be integrated with my version as well?

Even better would be to get the orphan list and then compare with the list post transaction and notify only new orphans.

I thought a hook for notifying pacnew and pacsave files would be a good idea. So here is a working prototype. Although it only checks /etc I've no experience of .pac* files being elsewhere.

I'm sure @mbb 's comment applies to this also :wink: and in general if anyone who can actually code (rather than just noob-cut-paste) wants to make it better then please to do so.


That's a cool idea. I went another route and tied it in with bash aliases into my update process. You must have mlocate installed for this method to work. After my update is complete, a list of pacnew files is written to my desktop.

alias pacnew='sudo updatedb && locate --existing --regex "\.pac(new|save)$"'
alias pacdiff='sudo -H DIFFPROG=kompare pacdiff'
alias mirrors='sudo pacman-mirrors --country Canada United_States'
alias download='sudo pacman-mirrors --country Canada United_States && sudo pacman -Syyuw'
alias update='download && sudo pacman -Su && pacnew > ~/Desktop/pacnew.log'

you could also just use
pacdiff -o


Way to take all the fun out our cool little projects we dream up. :smile:


Thanks I was not aware of that command. It made it simple enough that I could extend the use of my copy-paste skills. :stuck_out_tongue_winking_eye:

Definitely an improvement, in my opinion.


The baloo file search feature has been much improved in KDE. However, it is still not my favorite search engine and I would rather have it permanently disabled. According to the ArchWiki baloo can't be uninstalled, and it may be automatically re-enabled during a system upgrade. The ArchWiki recommends disabling baloo after any system upgrade if you do not want it run.

I decided to create a pacman hook to do this automatically after every system upgrade.

Here is the pacman hook

Type = Package
Operation = Upgrade
Target = /usr/bin/baloo_file

Description = Disable baloo file indexer after every upgrade operation
When = PostTransaction
Exec = /bin/sh -c 'killall baloo_file ; mv /usr/bin/baloo_file /usr/bin/baloo_file.bak ; echo '#!/bin/sh' > /usr/bin/baloo_file'


Interesting. When I read the Archwiki on disabling Baloo I didn't see that mentioned. Perhaps we're looking at two different pages?

The reason I mention this is it's one of the first things I turn off on an install in KDE. I think it's well, not any good. Not to disparage the KDE team but it's meh IMHO.
I use AngrySearch and Albert.
And now that I check balooctl status I see the little twerp is indeed running. /sigh
Another hook to add to the list. It's growing quickly because of you. :construction::construction_worker_woman:

1 Like

I'm curious if I can use my Gdrive?
But it's using KIO-GDrive so the location is funky.
It's gdrive:/
Will pacman understand that and dump the files there?
I'm scared to try it. The last time I tried automating something with GDrive google flipped out and locked my account.

well try with test email account.
its not like having thousands of Gmail id is not allowed.
but managing some tens of id is real pain forget about lot of them.

No worky. :frowning:
I guess pacman doesn't understand what gdrive:/ is. Oh well, back to derpbox

EDIT: aha! Victory! I read up in KIO-GDrive and found out it's just slaving the files. It is using a placeholder file to show you your gdrive. They aren't actually there until you click on them. This would explain the hook behavior.
So some research later and ODrive is the answer. It actually syncs to a folder on your drive.
So I have my pacman hook working the way I want now. Wooohooo!:partying_face:

I am ready for more :wink:

:: Starte post-transaction hooks...
(1/3) Orphaned package notification
=> No orphans found.
(2/3) Checking for .pacnew and .pacsave files...
.pac* files found:

Please check and merge
(3/3) No errors ...     # Also known as "ArmingConditionNeedsUpdate..." ;-)

Maybe cleaning dir :smiley:

~ >>> ls -la /home/sgs/bin/pacman-list/                                                                                               
insgesamt 120K
drwxr-xr-x  2 sgs  sgs  4,0K 23.06.2019 20:25  ./
drwxr-xr-x 12 sgs  sgs  4,0K 23.06.2019 17:57  ../
-rw-r--r--  1 sgs  sgs    30 23.06.2019 12:18 '2019-06-23@12:18_alien.txt'
-rw-r--r--  1 sgs  sgs  9,7K 23.06.2019 12:18 '2019-06-23@12:18_native.log'
-rw-r--r--  1 root root   30 23.06.2019 14:13 '2019-06-23@14:13_alien.txt'
-rw-r--r--  1 root root 9,7K 23.06.2019 14:13 '2019-06-23@14:13_native.log'
-rw-r--r--  1 root root   30 23.06.2019 14:18 '2019-06-23@14:18_alien.txt'
-rw-r--r--  1 root root 9,6K 23.06.2019 14:18 '2019-06-23@14:18_native.log'
-rw-r--r--  1 root root   30 23.06.2019 14:21 '2019-06-23@14:21_alien.txt'
-rw-r--r--  1 root root 9,6K 23.06.2019 14:21 '2019-06-23@14:21_native.log'
-rw-r--r--  1 root root   30 23.06.2019 14:22 '2019-06-23@14:22_alien.txt'
-rw-r--r--  1 root root 9,6K 23.06.2019 14:22 '2019-06-23@14:22_native.log'
-rw-r--r--  1 root root   30 23.06.2019 16:37 '2019-06-23@16:37_alien.txt'
-rw-r--r--  1 root root 9,6K 23.06.2019 16:37 '2019-06-23@16:37_native.log'
-rw-r--r--  1 root root   30 23.06.2019 20:25 '2019-06-23@20:25_alien.txt'
-rw-r--r--  1 root root 9,6K 23.06.2019 20:25 '2019-06-23@20:25_native.log'


Forum kindly sponsored by