Re: command_not_found_handle strange behaviour
On 3/29/18 12:08 PM, Eduardo A. Bustamante López wrote:
> 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:
These are mostly spot-on, except that it depends on whether the shell has
job control enabled, not whether it's interactive (that's when it tries to
manipulate process groups), though the behavior is slightly different.
It will be fixed in the next devel branch push.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: command_not_found_handle strange behaviour
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.
command_not_found_handle strange behaviour
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2
-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-Wno-parentheses -Wno-format-security
uname output: Linux articunoIceCave 4.15.13-1-ARCH #1 SMP PREEMPT Sun Mar 25
11:27:57 UTC 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
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:
command_not_found_handle()
{
read line
echo "$line"
}
bash-4.4$ foo
smth
smth
bash-4.4$
Repeat-By:
call some command which doesn't exist with different handlers
--
Кириллов Дмитрий
