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
  • 123
  • 5
  • 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
  • 368
  • 1
  • 10