Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16011

Re: command_not_found_handle() flaw

Show key headers only | View raw

Hi All,

I think it is a bug, it is not working as intended at least in the man
page, it says.

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.  If that function is not defined, the shell prints an
 error
       message and returns an exit status of 127.

A function invocation, don't imply a sub shell.

Secondly, if yuio insist on going on the subshell path, then $$ and $PPID
ought to be setup appropriately, here ther are plain bogus.

Third, the argument saying to late we forked already is dumb, it is too
late because the sequence

hookf = find_function (NOTFOUND_HOOK);
execute_shell_function (hookf, wl);

is misplaced after the fork, while it should be done before the fork.

I provided a fix that no one tested, that don't jeoparise the existing code
or behavior, and to respect what a function invocation is.

I can survive a "don't fix" well I can fix for myself, but has it is you
must at least fix 2 points, fix the doc, sayin the
command_not_found_handle() is called in a subshell and fix $$ and $PPID
that are bogus in the subshell.

BTW fixing $$ and $PPID will take more effort that just placing the hook
before the fork,  but that's your decision indeed :)

I think that either command_not_found_handle() is a gross hack to satisfy
command-not-found distro package, and in this case it should simply not be
documented in the docco, or else it should be done as specifed i.e a
function incovation is not a subshell running a function, that frankly is a
bit ridiculous.

Cheers,
Phi

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: command_not_found_handle() flaw Phi Debian <phi.debian@gmail.com> - 2020-03-10 20:57 +0100

csiph-web