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: [...] >> Hm. execvp explicitly does this when it hits ENOEXEC, but not for >> ENOENT. Do you know why that is? > > 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. Oh --- now I get it. This is about the optimization to bypass the shell in prepare_shell_command. It has nothing to do with execvp --- our execvp emulation already does the right thing, and Brandon's patches did not make this problem any worse or better. Unconditionally falling back to sh -c when we get ENOENT in the RUN_USING_SHELL case makes sense to me. Sorry for the confusion, Jonathan