Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: GNUser on October 08, 2019, 07:42:54 AM
-
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.
-
Hi GNUser
If you add this to the shebang:
#!/bin/sh -x
you can trace the execution and maybe find a clue.
-
Thank you Rich.
I tried that and also logged the exit codes.
Interestingly, the exit codes of
pgrep -f 'regex'
and
pgrep -f 'regex' >/dev/null
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.
-
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).