Re: command_not_found_handle strange behaviour

[Eduardo A . Bustamante López]

On Wed, Mar 28, 2018 at 06:42:21PM +0300, Кириллов Дима wrote:
[...]
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
> 
> Description:
>       I can't understand why read works without subshell before it, 
> but with subshell before read it stops
> 
>     command_not_found_handle()
>     {
>         (true) # subshell call
>         read line
>         echo "$line"
>     }
> 
>   bash-4.4$ foo
>   
>   [1]+  Stopped                 foo
> 
> And without subshell call it works fine:

I can reproduce this.


A few observations:

(1) `read' is stopped because it's in a different process group (i.e. it's a
background process), and background process that attempt to read from the
controlling terminal receive a SIGTTIN from the kernel.

(2) The subshell is a red herring. You can replace it with anything that causes
bash to fork a new process, e.g. /bin/true

(3) This behaviour was apparently introduced in bash-20151113 snapshot
(f9b024c839a3bbb9c6c2a98a16b1cf362010340a), although due to the nature of that
change, I suspect this issue has been present for far more time, and it was just
"uncovered" by this commit.

(4) This only affects interactive shells.

(5) The command_not_found_handle executes in a child process, i.e. the process
that was intended to be used by the not found program. Apparently it also
executes in its own process group, so it means that it should consistently
behave as a background process.