In the subject you wrote “successful full sys update” but the script and the other suggestions I see so far don’t actually handle the “successful” part.

The log message only tells you that the update was started and the db mtime only indicates that the db was touched without saying anything about success.

I’d go about this by always performing the updates through a wrapper script that could check the exit status of the pacman or yay command and record a timestamp accordingly.

I’d start by comparing the following in the working vs non-working cases:

1. Is there a corresponding /dev/input/js* device?
2. If it’s there in both cases, any difference in permissions? Check both regular Unix perms using ls -l or stat and ACLs using getfacl

1. The basics: high quality terminal emulation with utf-8 and directcolor support
2. Customization is by simple git friendly text config. Build time config (ala st) is acceptable if done in a reasonable way.
3. A way to pipe panes into external commands to allow for customized url and other other data extraction. Built-in regexs are not always enough and doing it on the tmux side is not always ideal.
4. Control over key bindings and mouse behavior
5. Small, very fast, instantaneous startup
6. Very predictable behavior, no surprises
7. Minimal dependencies (including build time) are a plus. Definitely no 100MB+ electron beasts.
8. Support X11 since I am sticking with that for now
9. A codebase I can understand in case I need to change it. Simple and fast build. For core tools like terminal emulators I must be able to build or modify them without much trouble.
10. Not too much extra junk. I don’t use menus, tabs, scrollbars etc so I don’t want the terminal to be huge or slow to support every feature others might want. I will put up with some extras if they can be completely disabled and don’t significantly affect performance or startup time or code complexity.
11. Absolutely no network service integration, no matter how well intended. The only acceptable network activity is talking to the X11 socket.
12. Longevity. I like to use my tools for years and years. I am interested in new tech of course but I don’t hop from one hype train to the next.

I know this is not everyone’s cup of tea but you asked what I want. And nowadays it’s at least as much about do not wants as wants.

I briefly tried ghostty when it was going around earlier. Slow startup time (~250ms if I remember right), the gtk-4 dependency and some weird defaults like the client side decoration (which I gather can be turned off in config) made me pass on it for now but might take another look in a few months. It didn’t seem particularly revolutionary to me either but there are plenty of much worse options out there too.

Any naming convention is fine as long as it’s meaningful to you. But it’s a good idea to keep your own repos separate from the random ones you clone from the internet.