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 -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html