2

I've installed pidof via homebrew

brew install pidof

And think about two cases:

$ pidof bash > /dev/null; echo $?
$ pidof asdf > /dev/null; echo $?

The results are:

0
0

Why does it happen? Other linux throw 1 when pidof couldn't find process.

3
  • "echo $?" is simply showing you whether or not the previous command, in this case "pidof" exited with an error code. 0 means success, any value greater than 0 is an error. I've never used pidof, but surely it returns the process ID of the process you pass it, why are you directing that output to /dev/null? surely "pidof bash" or "pidof asdf" will give you what you what you want?
    – MorganR
    Nov 3, 2015 at 14:46
  • Redirecting to /dev/null is just because I don't want to see PID (if it exists). What I wonder is, pidof of linux throws 1 if no PID found, but pidof of Mac OS X always throws 0 even if it doesn't find PID.
    – Jeon
    Nov 3, 2015 at 14:48
  • In that case, I don't know why echo $? would return 1 instead of 0 on Linux assuming there was no error. Hopefully someone else will have an explanation :)
    – MorganR
    Nov 3, 2015 at 14:54

2 Answers 2

3

The reason is that the pidof from HomeBrew is a different program than pidof in Linux. Even though they share the same name, and parts of the same functionality, they're actually quite different.

For example the HomeBrew pidof will also kill processes for you when specifying the -k argument, which Linux pidof cannot do. In contrast Linux pidof lets you specify you only want a single PID returned in single-shot mode with the -s parameter, the HomeBrew version hasn't got such an option. There are many other differences.

On Linux, pidof comes from the ubiquitous sysvinit-tools package. When you do a pidof programname in Linux, it loops through the running processes while keeping track of whether or not it found the program name you're looking for. If it doesn't find it, it returns an exit status of !0 (which is 1).

In HomeBrew, pidof is a standalone utility from "Night Productions". Their program has no source in common with the Linux pidof, and does not track whether or not it found the program name. It always returns an exit status of 0 in any case.

3
  • Uups, my bad, the pidof in my local bin folder wasn't installed via Homebrew...
    – nohillside
    Apr 13, 2020 at 12:10
  • @jksoegaard Are you sure that the procps package from sourceforge contains pidof? I cannot find any trace of the pidof command in procps-3.2.8.tar.gz. Apr 13, 2020 at 21:11
  • @OrtomalaLokni Ah, you're right - examined the source code of both programs before writing this, but I accidentially wrote the wrong project name here... procps contains a lot of other stuff that is related, but not here.
    – jksoegaard
    Apr 13, 2020 at 22:19
3

If you look at the Homebrew formula of pidof, you will see that the Homebrew version is built from : http://www.nightproductions.net/downloads/pidof_source.tar.gz

If you look at the source code pidof.c used by Homebrew, you will see that each occurrence of the return statement in the main function, is in the form:

return 0

except one time, when the usage of the command is printed:

printf("USAGE: %s [-klvh] [PID name]\n",ProgName);
                return 1;
                break;

On the other hand, in Linux distributions, such as Debian, the pidof command is coming from the System V style init programs. If you download the source code and look at killall5.c (which is then linked to pidof), you have at the last line of the main function:

return retval;

where retvalcan be non-null.

So the main reson why the Homebrew version of pidof and the Linux version of pidof return different values is because they use different codebase.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .