ignoring current shell and always running posix shell? Re: Should this be this way?

[Linda Walsh]

Pierre Gaston wrote:
> On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus <rrakus@redhat.com> wrote:
>> I think the line above will produce unspecified behavior.

> 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.
----
        I doubt that starting a different shell than the one you are
running under is going to preserve commands in the same way as the parent
UNLESS the parent is the same shell.

        Has passing such hashed args been standardized between zsh/tcsh,ksh
/sh/bash?


> 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.
----

        It is likely that the document is assuming you are running on
a POSIX compliant system where all users use the same shell so there is
only 1 shell, thus the use of the word 'the' when referring to the shell.

        Question -- is the above behavior required everywhere?  I.e. if
you are executing python or perl and execute something without a #!, then
the posix shell would be started?

        What is the user is running /bin/rsh or /bin/rbash?  I.e. if the wording
*truly* indicates that /bin/sh is the correct answer, under any interpretation,
then that seems to imply that such is true when running under rbash/rsh, as
they are not mentioned as exceptions.