Re: Checking executability for asynchronous commands

[Dale R. Worley]

Markus Elfring <Markus.Elfring@web.de> writes:
> I imagine that it can be occasionally helpful to determine the execution 
> failure
> in the synchronous way.
> Would it make sense to configure the error reporting for selected asynchronous
> commands so that they would become background processes only after the 
> required
> check for executability?

In many situations, you can check whether a command is executable with
[[ -x name ]]

As a general rule, Bash provides functionality which matches the direct
way to implement an operation using Unix.  In the case of "command &",
the direct way is "(1) fork a subprocess, (2) the subprocess does an
exec() of command".  The consequences are that (a) the parent process
has no information about the subprocess until it executes a wait() for
the subprocess, and (b) the subprocess, while executing bash, has no
information about whether "command" is executable until it executes
exec() -- if the command is not executable, the exec() will fail and
bash will print an error message and exit with an error, but if the
command is executable, the subprocess bash is immediately replaced by
the command.  In particular, there is no way for it to report to the
parent process that the exec() has been successfully executed.

With this sequence of operations, there is no way for the parent bash to
know in advance whether "command" is executable.  Of course, with
further operations, it could first test whether "command" is executable,
but that is effectively the same as performing "[[ -x command ]]" in the
bash script before performing "command &".  (And it has the same
difficulty regarding race conditions.)

Dale