ignoring current shell and always running posix shell? Re: Should this be this way?
Pierre Gaston wrote: > On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus 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.
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On Mon, Mar 11, 2013 at 7:11 PM, Linda Walsh wrote: > Pierre Gaston wrote: >> On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus 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. Correct, that's why bash doesn't do that (at least an upstream not patched version that the manual is documented) > Has passing such hashed args been standardized between zsh/tcsh,ksh > /sh/bash? I don't know >> 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. > Of course, it's the posix specification for the posix shell
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
Pierre Gaston wrote: >> >> >> 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. >> > Of course, it's the posix specification for the posix shell What does that say about bash (in nonposix mode), perl, python, rbash, etc i.e. -- the case that I ran into was NOT me running in posix mode. It would make no sense for posix to take the stance that any unknown script without a shebang at the top, presented to any interpreter shell be ignored by the interpreter and instead shall be run under /bin/sh. Posix used to claim they were "descriptive", not "prescriptive", though they are becoming more of the latter with each new update, I'd find it hard to think they'd try to enforce all script languages to default sources to /bin/sh.
