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