On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus <rra...@redhat.com> wrote: > On 02/26/2013 02:03 AM, Linda Walsh wrote: >> >> My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well. >> Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash. > > which is not always correct. Use type builtin. > >> >> I had the foll0wing script which acts differently based on >> whether or not it has a #!/bin/bash at the top: (i.e., as it is >> displayed below, it fails; one need remove the [] from the first >> line for it to work. >> ================ >> #[!/bin/bash] > > I think the line above will produce unspecified behavior.
I think the kernel will try to find a shebang and not recognize it, then the current shell will try to run it Man bash says: If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child. SUS says If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name. 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.