On Tue, May 16, 2017 at 10:15:40AM -0700, Brandon Williams wrote:
> > > > So I was thinking something like the patch below, though I guess
> > > > technically you could look for BASH_FUNC_$argv[0]%%, which seems to be
> > > > bash's magic variable name. I hate to get too intimate with those
> > > > details, though.
>
> One concern with that is what about all other shells that are not BASH?
> I'm sure they use a different env var for storing functions so we may
> need to handle other shell's too? That is assuming we want to keep the
> old behavior.
Most other shells don't do function-exporting at all. Certainly dash and
most traditional bourne shells don't. I wouldn't be surprised if zsh
does. But yeah, we'd have to support them one by one (and possibly
variants across different versions of each shell). Workable, but gross.
> > When execvp(foo) falls back on ENOEXEC, it is not running "sh -c foo".
> > It is actually running "sh foo" to run the script contents. So it's
> > about letting you do:
> >
> > echo "no shebang line" >script
> > chmod +x script
> > ./script
> >
> > And nothing to do with shell builtins.
>
> That's correct, and is the exact behavior I was trying to mimic with the
> changes to run_command.
> 1. try executing the command.
> 2. if it fails with ENOEXEC then attempt to execute it with a shell
I think the logic here would be more like:
1. During prepare_shell_cmd(), even if we optimize out the shell call,
still prepare a fallback argv (since we can't allocate memory
post-fork).
2. In the forked child, if we get ENOENT from exec and cmd->use_shell
is set, then exec the fallback shell argv instead. Propagate its
results, even if it's 127.
That still means we'd prefer a $PATH copy of a command to its shell
builtin variant, but that can't be helped (and I kind of doubt anybody
would care too much).
-Peff
