Re: command_not_found_handle documentation omission

[Dan Douglas]

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.

signature.asc
Description: OpenPGP digital signature