Re: command_not_found_handle documentation omission
On 10/08/2017 03:11 PM, Eduardo A. Bustamante López wrote: > I guess that instead of changing the semantics of > command_not_found_handle, a new special trap could be added that > executes in the context of the shell performing the command lookup. Possible, but magic traps can be ugly. I often end up just calling a function from one, otherwise there's no locals or positional params, though you do get to see the params of the calling context as compensation. A trap would need a new way to pass in the command name and args. > Although I'm not sure how valuable it would be (the added complexity). > Are there any serious uses of the command_not_found_handle aside from > suggestions during interactive use? Mostly non-serious uses in bash libraries that implement wacky features. command_not_found handle is the only "special" function in bash at the moment. It's reminiscent of discipline functions, which would be a sensible place to put this. Huge feature to implement though unless maybe the dynamic variable code can be substantially reused. signature.asc Description: OpenPGP digital signature
Re: command_not_found_handle documentation omission
On Sun, Oct 08, 2017 at 11:16:33AM -0500, Dan Douglas wrote: [...] > 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. > I guess that instead of changing the semantics of command_not_found_handle, a new special trap could be added that executes in the context of the shell performing the command lookup. Although I'm not sure how valuable it would be (the added complexity). Are there any serious uses of the command_not_found_handle aside from suggestions during interactive use?
Re: command_not_found_handle documentation omission
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
Re: command_not_found_handle documentation omission
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
Re: command_not_found_handle documentation omission
On 10/8/17 4:54 AM, Dan Douglas wrote: > On 10/07/2017 02:53 PM, Martijn Dekker wrote: >> The bash manual and info pages state: >> >> | If the search is unsuccessful, the shell searches for a >> | defined shell function named 'command_not_found_handle'. If that >> | function exists, it is invoked with the original command and the >> | original command's arguments as its arguments, and the function's >> | exit status becomes the exit status of the shell. >> >> This fails to mention that command_not_found_handle() is run in the >> subshell forked to 'exec' the command, so even an explicit 'exit' will >> not exit anything but that subshell. It also means a command handler >> can't do anything that influences the main shell, except send it a >> signal with 'kill'. > > Yeah I wish it didn't do that. If I wanted a subshell I'd add one myself. 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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: command_not_found_handle documentation omission
On 10/07/2017 02:53 PM, Martijn Dekker wrote: > The bash manual and info pages state: > > | If the search is unsuccessful, the shell searches for a > | defined shell function named 'command_not_found_handle'. If that > | function exists, it is invoked with the original command and the > | original command's arguments as its arguments, and the function's > | exit status becomes the exit status of the shell. > > This fails to mention that command_not_found_handle() is run in the > subshell forked to 'exec' the command, so even an explicit 'exit' will > not exit anything but that subshell. It also means a command handler > can't do anything that influences the main shell, except send it a > signal with 'kill'. Yeah I wish it didn't do that. If I wanted a subshell I'd add one myself. signature.asc Description: OpenPGP digital signature
Re: command_not_found_handle documentation omission
On 10/7/17 3:53 PM, Martijn Dekker wrote: > The bash manual and info pages state: > > | If the search is unsuccessful, the shell searches for a > | defined shell function named 'command_not_found_handle'. If that > | function exists, it is invoked with the original command and the > | original command's arguments as its arguments, and the function's > | exit status becomes the exit status of the shell. > > This fails to mention that command_not_found_handle() is run in the > subshell forked to 'exec' the command Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
command_not_found_handle documentation omission
The bash manual and info pages state: | If the search is unsuccessful, the shell searches for a | defined shell function named 'command_not_found_handle'. If that | function exists, it is invoked with the original command and the | original command's arguments as its arguments, and the function's | exit status becomes the exit status of the shell. This fails to mention that command_not_found_handle() is run in the subshell forked to 'exec' the command, so even an explicit 'exit' will not exit anything but that subshell. It also means a command handler can't do anything that influences the main shell, except send it a signal with 'kill'. The phrasing "the function's exit status becomes the exit status of the shell" is misleading to anyone without this knowledge, as it implies that the shell will exit with that status, whereas in fact all that happens is that $? is set to the function's exit status. - Martijn
