Re: git rebase regression: cannot pass a shell expression directly to --exec
- Date: Tue, 16 May 2017 10:30:41 -0700
- From: Brandon Williams <bmwill@xxxxxxxxxx>
- Subject: Re: git rebase regression: cannot pass a shell expression directly to --exec
On 05/16, Jeff King wrote:
> 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%%, 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:
Oh yes, I was just saying what I did not taking into account how we
would solve this issue.
> 1. During prepare_shell_cmd(), even if we optimize out the shell call,
> still prepare a fallback argv (since we can't allocate memory
> 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).