[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: command_not_found_handle strange behaviour
From: |
Eduardo A . Bustamante López |
Subject: |
Re: command_not_found_handle strange behaviour |
Date: |
Thu, 29 Mar 2018 10:08:05 -0600 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
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.