(+Brandon Williams, who may have more context for execvp-related things) Hi,
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[0]%%, 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. Thanks, Jonathan
