I think you're referring to the glibc Hardware capabilities section in ld.so(8) which will additionally search glibc-hwcaps/$subarch in each search path directory first to load hwcap-aware builds of libraries.
One problem here is that you'd need to ensure that a) notify-send is installed, and b) it's the executable the program thinks that it is, rather than some other file with the same name. For example, looking for a notify-send on $PATH could be a security bug if the user is running a program with more permissions than they have themself, as they could cause the program to find a malicious notify-send executable rather than the one they were looking for. (This might end up not being a real problem in practice, though ā it would be rare for a program that isn't compatible with the current CPU architecture to be given elevated permssions.)
The way Unix works is you aren't supposed to worry about either of those things. You run the notify-send binary on your PATH. If it doesn't exist, you print a message on stderr and give up. If it exists but doesn't do the jobāfor a very abstract definition of "does the job"; the human controlling the machine is entitled to put a notify-send binary in the first directory on the PATH that discards all notificationsāthen the system is misconfigured and it's not your problem to fix it.
A set-id binary must sanitize its PATH (and a whole bunch of other environment variables) but this is not a new requirement, and nowadays it's my impression that set-id binaries are considered bad practice, period.
1 Like
That only works if you have an oracle telling you that notify-send is misconfigured, otherwise the only thing you see is the program immediately closing without any error message and at that point what tells you whether it's your problem to fix or not?
Then on Linux it is up to the user to run it again in a terminal, possibly with strace if there is nothing helpful on the terminal.
You might argue it is not good UX. You would be right if you argued that. There is a reason it isn't yet the year of the Linux desktop.
(I say that and I do run KDE on Linux. Make of that what you will.)
1 Like
Lest we go too far down the rabbit hole of notify-send: I don't think we should ever spawn a program for this. Printing a warning is one thing, spawning a program would be too much complexity with too many downsides.
7 Likes
Honestly I think it's a bug in most current Unix GUI environments that stderr messages from GUI applications are discarded. They should at least get logged somewhere, and if an application abends they should get surfaced to the user.
2 Likes
It used to end up in your Xorg log. Nowadays I think it ends up in your user's journald log.
I run my GUI applications with systemd-run so mine end up in the journal. I don't think the "main" desktops have gone this route however.
I use XFCE on Debian. Basically all applications I didn't open from a terminal have the same socket as stdout and stderr. This includes gdm-x-session, of which I see a lot of logs in my user journal. So it might be that gdm handles this.
Built-in GUI notifications sound like a scope creep. I'm worried that going down that path will just make the change more difficult, and delay or derail it. An stderr message would already be a good start, and the notification mechanism perhaps could be made extensible later.
9 Likes