Re: [PATCH] [INPUT] Catch attempts to run a directory as a script

[Jonathan Nieder <jrnieder@gmail.com>]

Herbert Xu wrote:
> On Wed, Oct 06, 2010 at 05:08:04AM -0500, Jonathan Nieder wrote:

>> But POSIX makes it clear enough that in "sh command_file",
>> command_file is supposed to be a file, not a directory.  So
>> diagnose this with an error message and exit with status 2.
[...]
> Is this required by POSIX? If not this is simply making dash
> bigger for no good reason.

Not clear.  I suppose POSIX usually doesn't require anything when the
caller screws up.

Jari Aalto quoted the DESCRIPTION section[1] (and some similar
passages):

>    The sh utility is a command language interpreter that shall
>    execute commands read from a command line string, the standard
> >> input, or a specified file. 

I don't find that alone very convincing.

Under OPERANDS[2]: if the path contains a slash, all the standard says
is "the implementation attempts to read that file".  If the path does
not contain a slash and the file is not in the working directory, the
implementation _may_ perform a search as described in "Command Search
and Execution".

During that search, after execve() fails, "if the executable file is
not a text file, the shell _may_ bypass this command execution. In
this case, it shall write an error message, and shall return an exit
status of 126." (emphasis mine).

So this behavior is allowed as an optional subset of an optional
behavior.  That may have guided the bash implementors:

 $ bash directory
 directory: directory: is a directory
 $ echo $?
 126

It's probably not required.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=548687
[2] http://www.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_05