Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15442 > unrolled thread

Re: shebang-less script execution not resetting some options

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: shebang-less script execution not resetting some options Greg Wooledge <wooledg@eeg.ccf.org> - 2019-10-01 08:41 -0400

#15442 — Re: shebang-less script execution not resetting some options

On Tue, Oct 01, 2019 at 04:14:00AM -0700, L A Walsh wrote:
> On 2019/09/30 14:39, Grisha Levit wrote:
> > A few of the recently-added shopt options aren't getting reset when
> > running a shebang-less script, this should fix it up:
> >   
> Suppose the shebang-less script is being run by an earlier version
> of bash.  Won't the new patch radically change the behavior of of
> such programs?

Bash executes an external program by forking, and then attempting to
exec the command it has been given.  If the kernel returns ENOEXEC,
bash reads 128 bytes from the file, sees if any of them are NUL, and
if not, it decides to execute the contents of the file itself.

Since bash has already forked, we're already in a subshell.  So bash
just cleans things up (it calls reset_parser() and initialize_subshell())
and then reads the commands from the file.

So, the version of bash that executes the shebang-less "script" is the
same as the version of bash that we began with.  There's no way it can
be an "earlier version".

> Does posix define the behavior of a child script with no interp-line?

I can't cite chapter and verse here, but basically every C program and
every shell handle it differently.

Bash allows a child of itself (a subshell) to read the commands.
GNU find -exec uses /bin/sh to run it.
zsh and csh both use /bin/sh to run it, I think.
systemd's ExecStart= refuses to run it (honors the ENOEXEC).  I think.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web