Re: git rebase regression: cannot pass a shell expression directly to --exec
- Date: Tue, 16 May 2017 09:41:24 -0700
- From: Jonathan Nieder <jrnieder@xxxxxxxxx>
- Subject: Re: git rebase regression: cannot pass a shell expression directly to --exec
(+Brandon Williams, who may have more context for execvp-related things)
Jeff King wrote:
> On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote:
>> One hack would be to look for BASH_FUNC_* in the environment and disable
>> the optimization in that case. I think that would make your case Just
>> Work. It doesn't help other oddball cases, like:
>> - you're trying to run a shell builtin that behaves differently than
>> its exec-able counterpart
>> - your shell has some other mechanism for defining commands that we
>> would not find via exec. I don't know of one offhand. Obviously $ENV
>> could point to a file which defines some, but for most shells would
>> not read any startup files for a non-interactive "sh -c" invocation.
> 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.
> Another option is to speculatively run "foo" without the shell, and if
> execve fails to find it, then fall back to running the shell. That would
> catch any number of cases where the shell "somehow" finds a command that
> we can't.
Hm. execvp explicitly does this when it hits ENOEXEC, but not for
ENOENT. Do you know why that is?
I think we want to behave consistently for shell builtins and for
exported functions --- they are different sides of the same problem,
and behaving differently between the two feels confusing.