[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: command_not_found_handle() flaw
From: |
Chet Ramey |
Subject: |
Re: command_not_found_handle() flaw |
Date: |
Tue, 10 Mar 2020 16:26:40 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 3/10/20 3:57 PM, Phi Debian wrote:
>
> 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.
It's not clear what version of bash you're using, but the current version
of the man page says clearly that the function is invoked in "a separate
execution environment" and the "exit status becomes the exit status of that
subshell."
>
> 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.
$$ doesn't change for separate execution environments like command and
process substitution, so it doesn't change here. The same with PPID.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/