0

I have a script by a third-party company that does not work properly. It is supposed to start a process. The executable file path and its arguments are passed as the first argument ($1) to the script:

[...]
echo "Good ´ol printf-debugging in 2022"
echo $1
$1 &> /dev/null &
ExitStatus=$?
PID=$!
echo "PID = " $PID
echo "ExitStatus (before wait) = " $ExitStatus
wait $PID
echo "ExitStatus (after wait) = " $ExitStatus
[...]

This prints:

Good ´ol printf-debugging in 2022
/opt/daq-logger/daq-logger /media/sdcard/daq
PID =  493
ExitStatus (before wait) =  0

And output stops there (but the command finishes).

Changing $1 &> /dev/null & to simply $1 & does not change the output. With just $1, the output stops after printing the path (and the command finishes too).

After an hour of poking around, I noticed that the involved binary file is missing execute permissions: rwxr--r--

Why is there no error shown? How do I make it show an error? Why does the script get a PID if the process wasn't actually started? Well... apparently. If there actually is a process started, what happens with it and its stderr (i.e. why don't I see it)?

Niko O
  • 133
  • I don't see a shebang, but if you are using bash (per the tag) then &> /dev/null will redirect the standard error stream (as well as the standard output stream). Unrelated, but you shouldn't be passing both the executable path and its argument(s) via a single positional parameter and relying on word splitting of the unquoted $1 to separate them. – steeldriver Aug 23 '22 at 13:13
  • @steeldriver The [...] at the start denotes, that the shown snippet is part of a bigger section of code. The actual file starts with #!/bin/sh. And it does execute, because I see the output. Unfortunately, the way the argument is passed is not exactly in my control. I just need to find out why it's not working. – Niko O Aug 23 '22 at 13:20
  • Show the full script you're running, and how you execute it, exactly. If the parts marked with [...] aren't related to the issue, remove them and show a minimal example of a script that exhibits the issue. Right now, there could be anything in the [...] that causes the problem, and we have no way of knowing. – ilkkachu Aug 23 '22 at 13:26
  • Now, the shell should print an error if the command is not executable, but of course you won't see that if errors are redirected to /dev/null. Remove that redirection and do it again. Yes, you mentioned that "does not change the output", but you also mentioned just $1, and we don't get to see what the exact output is for each exact script. – ilkkachu Aug 23 '22 at 13:28
  • ...and just in case, check that you're not running with set -e. – ilkkachu Aug 23 '22 at 14:00

1 Answers1

0

Immediately after your line

echo "Good ´ol printf-debugging in 2022"

you should add

COM=`echo "${1}" | awk '{ print $1}' `
test -x "${COM}" || ( echo "\t ERROR:  '${COM}' is not executable! ; exit 1 )

That will prevent the calling script from proceeding without the necessary pre-conditions.

Also, please note that the line

ExitStatus=$?

does not capture the exit status of $1, but of the success/failure of putting that command line in background, which from experience is almost always 0. To get the actual return code of a background process, you may want to look at this response.

Eric Marceau
  • 378