On 10/08/2017 10:41 AM, Dan Douglas wrote: > On 10/08/2017 09:47 AM, Chet Ramey wrote: >> It was originally intended to take the place of the error message that >> bash prints when it can't find a program to execute. That message was >> printed by the subshell forked to execute the command, so the message could >> be redirected (nearly ll shells do it that way). If you're going to run a >> command, you run it in the same context as the error message. > > Bash does PATH resolution prior to forking any subshell and no fork > happens when a command isn't found, right? Indeed I would expect error > messages to be printed by the process that tried resolving the command, > which I thought is usually not a subshell. > > ~ # strace -fe trace=process bash -c 'foo' > execve("/bin/bash", ["bash", "-c", "foo"], 0x7ffd42249af0 /* 61 vars */) > = 0 > arch_prctl(ARCH_SET_FS, 0x7f6bbde9fe00) = 0 > bash: foo: command not found > exit_group(127) = ? > +++ exited with 127 +++ > > Any redirections applied to the command ought to still apply to the > handler with or without the subshell, and a handler can always save > and restore FDs if it had to redirect output with exec. If the handler > wants to guarantee output to the tty it pretty much has to use /dev/tty, > again with or without the subshell. > > Anyway I know this isn't new and there's probably some code out there > that depends on the implicit subshell by now. >
Thinking out loud some more... it does make sense that a user in an interactive session expects commands to not alter their shell environment, and a badly written command_not_found_handle could do that, possibly without the user's knowledge on systems that put a handler in a global bashrc (likely the most common scenario). On the other hand a user that actually defines their own handler could have a million reasons to want to propagate some effect to the interactive process, e.g. defining an alias or altering PS1. Same for non-interactive scripts.
signature.asc
Description: OpenPGP digital signature