Off-Topic > Off-Topic - Tiny Core Lounge

unexpected pgrep exit code when running non-interactively

(1/1)

GNUser:
In a non-interactive shell script, foo in pgrep -f 'regex' && foo never runs.

However, foo in pgrep -f 'regex' >/dev/null && foo does run when expected.

If I try the commands in an interactive shell, foo always runs when expected.

One of the scripts I use daily is affected by this (on line 27):
https://github.com/bdantas/wifi-monitor/blob/master/wifi-monitor

The function icon_add is supposed to return immediately (without creating an icon) if an icon already exists. If I remove >/dev/null from line 27, however, the function never returns and icons pile up in the systray.

Any idea why >/dev/null is required here? I thought the exit code of a utility (pgrep in this case) should be the same regardless of where its output is going.

Rich:
Hi GNUser
If you add this to the shebang:

--- Code: ---#!/bin/sh -x
--- End code ---
you can trace the execution and maybe find a clue.

GNUser:
Thank you Rich.
I tried that and also logged the exit codes.

Interestingly, the exit codes of

--- Code: ---pgrep -f 'regex'
--- End code ---
and

--- Code: ---pgrep -f 'regex' >/dev/null
--- End code ---
are different ("1 1 1 1 1 ..." in the first case, "1 0 0 0 0 ..." in the second case). The expected exit codes are the second set.

Since the exit code of a command should not depend on where its output is going, I think I found a bug in pgrep. I'll contact the developers to inquire and will report back here with what they say.

 

GNUser:
I redirected the script's stderr to a log to investigate what's going on when pgrep -f 'regex' && foo fails to work as expected.

Lo and behold, a bunch of "pgrep: write error" entries show up in the log.

So it seems the issue here is that when a shell script runs in the background, pgrep gets grumpy unless its stdout is redirected somewhere (even if only to /dev/null).

Navigation

[0] Message Index