On 21/05/2019 16:16, Chet Ramey wrote:
I can't reproduce this using bash-5.0. I took your script, ran it, then
bound C-x to execute "echo abc":
[snip]
And hitting ^X gives me "abc". It doesn't matter whether or not I remove
the binding for \C-x itself.
I started a console and changed nothing
On 21/05/2019 23:33, Dennis Williamson wrote:
Why don't you unbind the keystrokes that are actually bound?
while read -r b; do bind -r "$b"; done < <(bind -p | awk -F ':' '/./
&& !/self-insert|accept-line|^#/ {gsub("\"", "", $1); print $1}')
That was my first approach when I dealt with this som
Date:Tue, 21 May 2019 22:11:20 +
From:Charles-Henri Gros
Message-ID:
| The existence or not of the file should not have any effect.
But it does, and is intended to. If the mattern matches a file
(when patyhname expanded as a result of the unquoted command s
On Wed, May 22, 2019 at 05:25:43PM +0700, Robert Elz wrote:
> Date:Tue, 21 May 2019 22:11:20 +
> From:Charles-Henri Gros
> Message-ID:
>
>
> | The existence or not of the file should not have any effect.
>
> But it does, and is intended to. If the mattern m
The Bash Reference Manual, Edition 5 and earlier versions define lists
of commands as follows:
"A list is a sequence of one or more pipelines separated by one of the
operators ..." (Bash Reference Manual 3.2.3).
Shouldn't that say commands rather than pipelines?
Ralph Jensen
On Wed, May 22, 2019 at 02:38:29PM +0800, Ralph Jensen wrote:
> The Bash Reference Manual, Edition 5 and earlier versions define lists of
> commands as follows:
>
> "A list is a sequence of one or more pipelines separated by one of the
> operators ..." (Bash Reference Manual 3.2.3).
>
> Shouldn't
> What still remains is the not working assignment of ^X.
>
> Henning
Hi, I guess you are using Bash 4.4 because, according to my records,
bind -x '"\C-x": ...' after unbinding all the keyseqs causes segfaults
in Bash-3.0, 3.1 and 4.0--4.2, infinite loops in Bash 3.2, and error
messages like "bash
On 5/22/19 4:47 AM, Henning wrote:
> On 21/05/2019 16:16, Chet Ramey wrote:
>>
>> I can't reproduce this using bash-5.0. I took your script, ran it, then
>> bound C-x to execute "echo abc":
> [snip]
>> And hitting ^X gives me "abc". It doesn't matter whether or not I remove
>> the binding for \C-x
Date:Wed, 22 May 2019 08:43:00 -0400
From:Greg Wooledge
Message-ID: <20190522124300.gz1...@eeg.ccf.org>
| It seems to be unique to bash 5. If it's a bug fix, then I'm not
| understanding the rationale. Backslashes shouldn't be consumed during
| glob expansion.
On 22/05/2019 14:58, Koichi Murase wrote:
What still remains is the not working assignment of ^X.
Henning
Hi, I guess you are using Bash 4.4 because, according to my records,
bind -x '"\C-x": ...' after unbinding all the keyseqs causes segfaults
in Bash-3.0, 3.1 and 4.0--4.2, infinite loops in
On 5/21/19 12:51 AM, Hengyang Zhao wrote:
> Dear bash developers,
>
> I found an unexpected behavior when engineering some code in a callback of
> DEBUG trap. The code has been distilled to expose this behavior:
>
> ### BEGIN
> my_func() {
> local x=$(:)
> }
> trap my_func DEBUG
> false | true
On 22/05/2019 16:27, Chet Ramey wrote:
On 5/21/19 12:51 AM, Hengyang Zhao wrote:
Dear bash developers,
I found an unexpected behavior when engineering some code in a callback of
DEBUG trap. The code has been distilled to expose this behavior:
### BEGIN
my_func() {
local x=$(:)
}
trap my_fun
On 5/22/19 9:33 AM, Robert Elz wrote:
> Date:Wed, 22 May 2019 08:43:00 -0400
> From:Greg Wooledge
> Message-ID: <20190522124300.gz1...@eeg.ccf.org>
>
> | It seems to be unique to bash 5. If it's a bug fix, then I'm not
> | understanding the rationale. Backslashe
On 5/21/19 5:33 PM, Dennis Williamson wrote:
> On Tue, May 21, 2019 at 3:04 AM Henning wrote:
>
>> On 20/05/2019 15:38, Chet Ramey wrote:
>>> On 5/19/19 10:43 AM, Henning wrote:
I don't like to have dozens of key bindings I never use. Currently I
am issuing lots of lots of bind -r/-u co
On 5/22/19 5:43 AM, Greg Wooledge wrote:
> On Wed, May 22, 2019 at 05:25:43PM +0700, Robert Elz wrote:
>> Date:Tue, 21 May 2019 22:11:20 +
>> From:Charles-Henri Gros
>> Message-ID:
>>
>>
>> | The existence or not of the file should not have any effect.
>>
>> Bu
On Wed, May 22, 2019 at 05:34:22PM +, Charles-Henri Gros wrote:
> On 5/22/19 5:43 AM, Greg Wooledge wrote:
> > Standard disclaimers apply. Stop using unquoted variables and these
> > bugs will stop affecting you. Nevertheless, Chet may want to take a
> > peek.
>
> What unquoted variables? Ar
On Wed, May 22, 2019 at 07:14:44PM +, Charles-Henri Gros wrote:
> The file name is the regex (argument to "-e"), not the file "grep"
> reads. I want to check that some text file contains a reference to a file.
>
> But it looks like this would work:
>
> for file in $(find ...); do grep -e "$(e
On 5/22/19 10:47 AM, Greg Wooledge wrote:
> On Wed, May 22, 2019 at 05:34:22PM +, Charles-Henri Gros wrote:
>> On 5/22/19 5:43 AM, Greg Wooledge wrote:
>>> Standard disclaimers apply. Stop using unquoted variables and these
>>> bugs will stop affecting you. Nevertheless, Chet may want to take
On 5/22/19 3:14 PM, Charles-Henri Gros wrote:
> That's what I find a bit surprising (but shells are complicated, so
> maybe this is right. All I know is that the code used to work). I didn't
> think glob expansions applied to command expansions.
Command substitution is one of the word expansions,
On Mai 22 2019, Charles-Henri Gros wrote:
> The file name is the regex (argument to "-e"), not the file "grep"
> reads. I want to check that some text file contains a reference to a file.
>
> But it looks like this would work:
>
> for file in $(find ...); do grep -e "$(echo -n "$file" | sed 's/\$
On Wed, May 22, 2019 at 05:34:22PM +, Charles-Henri Gros wrote:
[cut]
> The problem I'm trying to solve is to iterate over regex-escaped file
> names obtained from a "find" command. I don't know how to make this
> work. It works with other versions of bash and with other shells.
>
> The origin
Date:Wed, 22 May 2019 17:34:22 +
From:Charles-Henri Gros
Message-ID:
| The problem I'm trying to solve is to iterate over regex-escaped file
| names obtained from a "find" command. I don't know how to make this
| work. It works with other versions of bash
On 5/22/19 3:13 PM, Robert Elz wrote:
> Date:Wed, 22 May 2019 17:34:22 +
> From:Charles-Henri Gros
> Message-ID:
>
>
> | The problem I'm trying to solve is to iterate over regex-escaped file
> | names obtained from a "find" command. I don't know how to make t
Date:Wed, 22 May 2019 22:23:04 +
From:Charles-Henri Gros
Message-ID:
| But unfortunately, grep was just illustrative, I'm using another tool
| that takes a regex but has no "-F" option (though admittedly with some
| effort I could add one, I wrote the tool
24 matches
Mail list logo
