On 29/03/2023 12:37, Jesse Smith wrote:
Given subsequent discussion, could we instead use canonicalize_file_name
or realpath here instead? That would give us the "correct" path without
pidof having to think hard about symlinks et al.
I'm open to the possibility. I'm curious as to what you see as the pros
vs cons of changing the approach used by pidof?
Broadly, I think there is an expectation that
pidof $(which emacs)
works on Debian (et al) systems where alternatives are in use (or other
setups with >1 symlink), regardless of which user is running the emacs
(WLOG).
I think using realpath or canonicalize_file_name might simplify matters?
But I've not gone poking through the code in detail, just this talk of
more than one symlink confusing things made me think of these library
functions.
Perhaps as an aside, on my system with 3.06-2, I see different behaviour
depending on the user running the binary:
matthew@aragorn:~/junk$ ps waux | grep emacs
root 3905 0.0 0.0 165344 3976 tty1 T Mar06 0:00 emacs
/etc/mumble-server.ini
matthew 5149 0.0 1.0 453684 169224 ? Ss Feb11 61:26 emacs
--daemon
matthew 13119 0.0 0.3 214776 50076 pts/19 S Feb27 0:37 emacs
accparse.py
matthew@aragorn:~/junk$ pidof emacs
13119 5149 3905
matthew@aragorn:~/junk$ pidof $(which emacs)
3905
matthew@aragorn:~/junk$ pidof $(readlink -f $(which emacs))
13119 5149
Here $(which emacs) -> /usr/bin/emacs -> /etc/alternatives/emacs ->
/usr/bin/emacs-lucid
So the root process is picked up with pidof /usr/bin/emacs and the user
processes by pidof /usr/bin/emacs-lucid.
pidof emacs picks up all three.
In each case /proc/pid/exe is (a deleted version of) /usr/bin/emacs-lucid
HTH,
Matthew
