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/READ
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 misrea
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-ba
>
> 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
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 rec
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 cur
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
> $
> $ re
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
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.
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
Hello,
The following assertion succeeds when it should not :
set -e
! true
echo Hello # prints Hello but should not
Regards,
--
Florent Bordignon
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
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 wit
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
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
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
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. A
17 matches
Mail list logo
