Markus Elfring <markus.elfr...@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
