Backslash Bound Incorrectly (Readline)

[sunnycemetery]

Key sequences containing backslashes are bound incorrectly (and  
impossibly):



■ bind '"\C-\\":  undo'
■ LC_ALL=C bind -q undo
undo can be invoked via "\C-x\C-u", "\C-\\\".


Is this a bug?  Perhaps there is a reason I do not see.  Thank you.


■ grep -i version -m 1 /usr/share/doc/readline/README
This is the Gnu Readline library, version 8.0.
■ LC_ALL=C bash --version
GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+:  GNU GPL version 3 or later  



This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
■ uname -srvmo
Linux 5.5.13-arch2-1 #1 SMP PREEMPT Mon, 30 Mar 2020 20:42:41 +  
x86_64 GNU/Linux

Re: signals ignored in a subshell

[Robert Elz]

Date:Sun, 5 Apr 2020 16:21:53 -0400
From:Chet Ramey 
Message-ID:  <45c766ba-4489-bd7b-40c7-32fed3746...@case.edu>

  | That's not how read is defined to behave. wait has special wording defining
  | what happens when it receives a signal.

No, it doesn't, that's a misreading of the standard.

For both read and wait, POSIX says:

ASYNCHRONOUS EVENTS
Default.

where "default" is defined in XCU 1.4, and is specified to be the
default value for the signal (which for SIGINT is to cause the
process to terminate) unless the parent caused the signal to be ignored
(a utility - including a built-in utility - cannot inherit a trapped (caught)
signal from its parent).

When a SIGINT is received read should terminate, just as wait does, or
any other utility which does not itself catch SIGINT, does.

The wording you're referring to in the description of the wait
utility refers to its exit status, which is fairly precisely specified
for wait (exactly what the status should be in the various cases)
where read is just 0 if everything worked, >0 other cases.

bash and zsh seem to be the only shells that treat read this way, and
bash doesn't do it in POSIX mode, which means, I believe that you're
aware that you're treating read specially, and that what POSIX says about
it is irrelevant.

I'd make this an option to read, rather that a side effect of posix mode,
if I wanted to make it possible to restart reads, and in any case should
be documented.   Yes, I know this is #58 in
 http://tiswww.case.edu/~chet/bash/POSIX
but unless the man page at least hints that the way read works depends
upon posix mode, how would anyone know to look there?

  | Bash default mode behaves as I
  | described previously -- trapping the signal and returning from the handler
  | results in the read being restarted -- and posix mode will run the trap
  | handler before returning from the `read' builtin.

Even that didn't make it clear to me (#58 referred to above is better worded).

It is also worth pointing out, that only a caught signal works that
way, if SIGINT is in its deffault state, read is interrupted by a SIGINT
(the read doesn't restart).

kre

ps: yash is also broken here, but worse, which can only be the result of
a bug, SIGINT never interrupts read there, a SIGINT received while read
is running is acted upon after read completes - regardless of whether
SIGINT is trapped or not.

Re: Backslash Bound Incorrectly (Readline)

[Koichi Murase]

2020-04-06 17:54 :
> > ■ bind '"\C-\\":  undo'
> > ■ LC_ALL=C bind -q undo
> > undo can be invoked via "\C-x\C-u", "\C-\\\".
>
> Is this a bug?  Perhaps there is a reason I do not see.  Thank you.

This is fixed in the devel branch. See the following patch.
https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00037.html

--
Koichi

signals ignored in a subshell

[Oğuz]

>
> That's not how read is defined to behave. wait has special wording defining
> what happens when it receives a signal. Bash default mode behaves as I
> described previously -- trapping the signal and returning from the handler
> results in the read being restarted -- and posix mode will run the trap
> handler before returning from the `read' builtin.
>

Okay, you're right, in posix mode the behavior is as expected. However I
still didn't get why job controls being enabled/disabled changes the way an
interactive shell handles signals in posix mode. Like

$ set -o posix
$
$ trap 'echo foo' INT
$
$ read
^Cfoo
$ sleep 5
^C
$
$ set +m
$
$ read
^Cfoo
$ sleep 5
^Cfoo

Is there a race condition here or does posix mandate this behavior for
built-in utilities?


-- 
Oğuz

Re: signals ignored in a subshell

[Oğuz]

Or, is it that when job controls are enabled each synchronous command is
run in its own process group and SIGINT is not sent to the shell at all?

6 Nisan 2020 Pazartesi tarihinde Oğuz  yazdı:

> That's not how read is defined to behave. wait has special wording defining
>> what happens when it receives a signal. Bash default mode behaves as I
>> described previously -- trapping the signal and returning from the handler
>> results in the read being restarted -- and posix mode will run the trap
>> handler before returning from the `read' builtin.
>>
>
> Okay, you're right, in posix mode the behavior is as expected. However I
> still didn't get why job controls being enabled/disabled changes the way an
> interactive shell handles signals in posix mode. Like
>
> $ set -o posix
> $
> $ trap 'echo foo' INT
> $
> $ read
> ^Cfoo
> $ sleep 5
> ^C
> $
> $ set +m
> $
> $ read
> ^Cfoo
> $ sleep 5
> ^Cfoo
>
> Is there a race condition here or does posix mandate this behavior for
> built-in utilities?
>
>
> --
> Oğuz
>
>

-- 
Oğuz

Re: verbosity of DEBUG trap following edit-and-execute-command

[Chet Ramey]

On 4/5/20 8:45 PM, Ami Fischman wrote:
> On Sun, Apr 5, 2020 at 12:43 PM Chet Ramey  wrote:
>> Hence the discussion topic: should bash disable set -v when executing
>> the DEBUG trap, should it do that just while running commands from a
>> file while running `fc', or should it continue with its current behavior?
> 
> Thanks for clarifying the parameter space.
> For my purposes either of the first 2 options would work, but my only use of
> DEBUGhas been to muck with terminal state this way, so possibly users of DEBUG
> withless-visible side-effects would prefer it to stay as-is. Not sure if such
> usages exist orhow to trade-off the use-cases against each other.

I'm going to go with a variant of 2: a more general facility that only the
`fc' builtin uses. It will be in the next devel branch push.

Chet
-- 
``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: signals ignored in a subshell

[Chet Ramey]

On 4/6/20 8:03 AM, Oğuz wrote:

> Okay, you're right, in posix mode the behavior is as expected. However I
> still didn't get why job controls being enabled/disabled changes the way an
> interactive shell handles signals in posix mode. Like
> 
> $ set -o posix
> $
> $ trap 'echo foo' INT
> $
> $ read
> ^Cfoo
> $ sleep 5
> ^C
> $
> $ set +m
> $
> $ read
> ^Cfoo
> $ sleep 5
> ^Cfoo
> 
> Is there a race condition here or does posix mandate this behavior for
> built-in utilities?

When job control is enabled, commands are run in separate process groups,
and those process groups get terminal-generated signals like SIGINT. The
shell never sees them.

-- 
``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: signals ignored in a subshell

[Robert Elz]

Date:Mon, 6 Apr 2020 15:06:02 +0300
From:=?UTF-8?B?T8SfdXo=?= 
Message-ID:  


  | Or, is it that when job controls are enabled each synchronous command is
  | run in its own process group and SIGINT is not sent to the shell at all?

That would be correct.

kre

ps: the Subject of all of these messages is misleading, there hasn't
been an example where a subshell is involved.   There could be, but
none of the test cases for the various issues so far have invoked one.

Re: Backslash Bound Incorrectly (Readline)

[sunnycemetery]

On 2020-04-06 18:42, Koichi Murase wrote:

This is fixed in the devel branch. See the following patch.
https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00037.html


Indeed it is.  Thank you for the information and patch.  I apologize for  
overlooking this message in my searches.

Re: signals ignored in a subshell

[Chet Ramey]

On 4/6/20 5:12 AM, Robert Elz wrote:
> Date:Sun, 5 Apr 2020 16:21:53 -0400
> From:Chet Ramey 
> Message-ID:  <45c766ba-4489-bd7b-40c7-32fed3746...@case.edu>
> 
>   | That's not how read is defined to behave. wait has special wording 
> defining
>   | what happens when it receives a signal.
> 
> No, it doesn't, that's a misreading of the standard.

I wonder if we're talking about the same thing. I'm talking about how the
standard says wait will return immediately and then execute the trap
handler. There's no such wording for read, so there is some freedom in when
the trap handler gets executed. Bash does it in the context of `read',
before any specific return.

> bash and zsh seem to be the only shells that treat read this way, and
> bash doesn't do it in POSIX mode, which means, I believe that you're
> aware that you're treating read specially, and that what POSIX says about
> it is irrelevant.

Bash has implemented `read' this way forever, and backwards compatibility
is an issue. POSIX mode is posix mode: that's where what posix says has
relevance, and why bash behaves differently.

The better question, I think, is whether a posix-mode bash should
(logically) return from the read builtin before running the trap handler,
or run the trap handler and then return. That has implications for what the
OP was trying to do: a recursive trap handler.

Chet
-- 
``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/

Exclamation mark does not work with set -e

[fb]

Hello,

The following assertion succeeds when it should not :
set -e
! true
echo Hello # prints Hello but should not

Regards,

--
Florent Bordignon

Re: Exclamation mark does not work with set -e

[Greg Wooledge]

On Mon, Apr 06, 2020 at 04:33:15PM +0200, f...@florentbordignon.fr wrote:
> Hello,
> 
> The following assertion succeeds when it should not :
> set -e
> ! true
> echo Hello # prints Hello but should not

  -e  Exit  immediately  if a pipeline (which may consist of a
  single simple command), a list, or  a  compound  command
  (see SHELL GRAMMAR above), exits with a non-zero status.
  The shell does not exit if the  command  that  fails  is
  part  of  the command list immediately following a while
  or until keyword, part of the test following the  if  or
  elif  reserved  words, part of any command executed in a
  && or || list except the command following the final  &&
  or ||, any command in a pipeline but the last, or if the
  command's return value is being inverted with !.

(snip)

Re: Exclamation mark does not work with set -e

[Chris Down]

f...@florentbordignon.fr writes:

The following assertion succeeds when it should not :
set -e
! true
echo Hello # prints Hello but should not


Please do read the documentation before reporting bugs :-)

If you read the documentation for `-e`, you'll see that if the command is being 
inverted with `!`, `set -e` does not apply.

Re: signals ignored in a subshell

[Robert Elz]

Date:Mon, 6 Apr 2020 10:10:47 -0400
From:Chet Ramey 
Message-ID:  <3e31254d-cc8b-221c-ddb9-ea1ea9fa7...@case.edu>

  | I wonder if we're talking about the same thing.

We weren't, but it makes little difference.

  | I'm talking about how the
  | standard says wait will return immediately and then execute the trap
  | handler. There's no such wording for read,

Not specifically, what it says is ...

When a signal for which a trap has been set is received while
the shell is waiting for the completion of a utility executing
a foreground command, the trap associated with that signal shall
not be executed until after the foreground command has completed.

And then it goes on to the part about wait, which does say that wait
will stop immediately - the difference being, that other utilities can,
if they want, keep running - and the shell needs to wait for them.

Read is such a utility, and it was running in the foreground in all
given examples.

But read is not supposed to keep on running - since its acton on "async
events" (ie: signals) is "default", and since it has no mechanism to trap
signals itself, unless the shell has ignored sigint the read should get the
default action (as does most other utilities, like ls or cat) and
simply exit when the SIGINT is received.

  | so there is some freedom in when the trap handler gets executed.

There is, but not while the utility is still running.

But all of this is immaterial really, as we're discussing a non-posix
operation in bash, and if you're ignoring (deliberately deviating from)
posix, then what the standard says is obviously irrelevant.

  | The better question, I think, is whether a posix-mode bash should
  | (logically) return from the read builtin before running the trap handler,

Yes, certainly, in posix mode.   From what little testing I did, that's
what appears to happen (and what that #58 in the lis of posix mode
differences says happens - read exits with 128+signo status).

One other oddity that might be worth documenting, when "read -e" is
interrupted by a trapped SIGINT, it doesn't flush the input buffer.
(Without -e the terminal driver does it before anything ever gets received).

This seems to be the same in both posix mode, and non-posix mode
(of course, something using posix mode shouldn't be doing read -e
really).   If the SIGINT isn't trapped, it aborts the read, in both
modes (posix and not) when "read -e" is used.   I assume the SIGINT
handler could use readline functions to cause pending input to be flushed,
but that seems like a lot of work to expect trap handler to do, just to
get the normal SIGINT behaviour.

kre

Re: Exclamation mark does not work with set -e

[Florent Bordignon]

On 4/6/20 4:50 PM, Chris Down wrote:
> Please do read the documentation before reporting bugs :-)

Thanks Chris.

Sorry for having wrongly reported a bug.

Regards,

-- 
Florent Bordignon

Re: signals ignored in a subshell

[Chet Ramey]

On 4/6/20 12:00 PM, Robert Elz wrote:

> One other oddity that might be worth documenting, when "read -e" is
> interrupted by a trapped SIGINT, it doesn't flush the input buffer.
> (Without -e the terminal driver does it before anything ever gets received).

You mean the terminal's input buffer, or readline's line buffer with
characters it's already read?


-- 
``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: signals ignored in a subshell

[Robert Elz]

Date:Mon, 6 Apr 2020 15:44:08 -0400
From:Chet Ramey 
Message-ID:  <20735a7e-627d-763b-adf6-0d94203aa...@case.edu>

  | You mean the terminal's input buffer, or readline's line buffer with
  | characters it's already read?

As a user I don't distinguish the two cases.   All I see is input I
have typed, that hasn't yet been handed away to be processed, and which
I can still edit and correct if I desire.   When using readline I have
a fairly powerful editor to assist, when not, it is just delete backwards
and retype, so the ease of corrections varies, but the overall effect is
the same.

In (I think) all cases except read -e when there is a SIGINT trap,
if I type ^C I abort what I am doing, and everything entered so far is
discarded (whether, when appropriate, it ends up in history for later
recall if desired is irrelevant - it doesn't get processed as valid
input).

kre