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
