Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Markus Fischer]

Alright. Then there is still the issue with gdb, which is no symlink. A 
full example for that:

```shell 1

$ type gdb
gdb is /usr/bin/gdb
$ gdb --core=corefile

```

```shell 2

$ ./pidof gdb
23125
$ ./pidof $(which gdb)
$ ls -l $(which gdb)
-rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb

```

Am 23.03.23 um 15:25 schrieb Jesse Smith:
> On 2023-03-23 11:20 a.m., Markus Fischer wrote:
>> ```shell 1
>>
>> $ type vi
>> vi is /usr/bin/vi
>> $ vi
>>
>> ```
>>
>> ```shell 2
>>
>> $ cd ~/src/sysvinit-upstream/src/
>> $ ls -l pidof
>> lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5
>> $ ./pidof vi
>> 21945
>> $ ./pidof $(which vi)
>> $ ls -l $(which vi)
>> lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi ->
>> /etc/alternatives/vi
>> $ ls -l /etc/alternatives/vi
>> lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi ->
>> /usr/bin/vim.tiny
>> $ ls -l /usr/bin/vim.tiny
>> -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny
>
> Okay, yes, this makes sense. The symbolic links are making multiple
> jumps so it won't work. This is expected behaviour because there is no
> executable running called /usr/bin/vi or /etc/alternatives/vi. Running
> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to
> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't
> follow aliases or symbolic links with multiple hops and different names.
>
>