Re: Bug report in ubuntu 24.04

This isn't a bug in bash. You might find some of the suggestions in https://github.com/rstudio/rstudio/issues/8539 helpful. On Sun, Oct 6, 2024, 18:02 Luis Vazquez de Lara via Bug reports for the GNU Bourne Again SHell wrote: > Reporting a bug after in RStudio terminal with the aliases > > Dr. L

Bug report in ubuntu 24.04

Reporting a bug after in RStudio terminal with the aliases Dr. Luis Guillermo Vázquez de Lara Cisneros.Laboratorio de Medicina Experimental Facultad de Medicina  Benemérita Universidad Autónoma de Puebla Tel. (222) 229-55-00 ext. 6074 dead.bashbug Description: Binary data

Re: Bug report for pretty-printing coprocesses with simple commands

On 2/27/24 7:25 PM, Seth Sabar wrote: Hi, I'd like to report a bug with the *--pretty-print* feature of bash. When I run the following script: *coproc sleep 5* the pretty-printed result is *coproc COPROC* sleep 5 Thanks for the report. This issue was fixed back in December as the result of

Bug report for pretty-printing coprocesses with simple commands

Hi, I'd like to report a bug with the *--pretty-print* feature of bash. When I run the following script: *coproc sleep 5* the pretty-printed result is *coproc COPROC* sleep 5 The reason this happens is because within Bash's AST every *coproc* is given a name regardless of whether the user spec

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On 2022/03/20 02:20, Michaelll Lee wrote: When ``PS1’’ environment variable contains the ANSI escape codes, Bash will behavior unexpectedly when Copy&Paste the content from clipboard using Ctrl+V. This unexpected behaviour could be easily reproduced in a few steps. Reproduceable steps are: 1) $

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mar 21, 2022, 9:39 PM Dennis Williamson wrote: > > Note that the difference you see in Bash 5 is due to new paste behavior. >From the perspective from users, would be more appropriate to see a hint for this new kind of behavior in man page/manual. Anyway, thanks for the clarification. On Mo

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mar 21, 2022, 9:47 PM Chet Ramey wrote: > Unless told otherwise, it assumes that every character it outputs contributes > to that physical cursor position. Thank you Sir, for pointing out this clearly, and now I think my previous thoughts would be my misunderstanding. On Mon, Mar 21, 2022 at

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On 3/21/22 5:00 AM, Michaelll Lee wrote: While using non-printing characters without "\[...\]" proves to be fine in versions prior to 5.x.x (e.g., many suggestions from some online forums have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the same configuration in 5.x.x is not

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mon, Mar 21, 2022 at 4:01 AM Michaelll Lee wrote: > . . . > While using non-printing characters without "\[...\]" proves to be fine in > versions prior to 5.x.x (e.g., many suggestions from some online forums > have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the > same co

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mon, Mar 21, 2022 at 05:00:29PM +0800, Michaelll Lee wrote: > By the way, apparently the content about "non-printing characters" in that > man page has not been modified across the several versions of Bash, for > example in my machine, "3.2.57(1)-release" and "5.1.0(1)-release" share > nearly t

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

@Andreas Have it solved by following that manual page and using "\[ ... \]" combination. Thanks for the hint! By the way, apparently the content about "non-printing characters" in that man page has not been modified across the several versions of Bash, for example in my machine, "3.2.57(1)-releas

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mär 20 2022, Michaelll Lee wrote: > 1) $ PS1='---Test \\ \e[0m ---\\$ ' Read the manual about non-printing characters in the prompt. https://www.gnu.org/software/bash/manual/html_node/Controlling-the-Prompt.html -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4

[Bug Report] The Unexpected Behavior When Using ANSI Escape Code

*Below are generated automatically by **'/usr/bin/bashbug' due to the absence of 'rmail**’** command.* --- *From:* Michael(lwl2...@gmail.com) *To:* bug-bash@gnu.org *Subject: *The Unexpected Behavior When Using ANSI

Re: bug report

you wrong set set -e shopt -s extglob da=( ?(a)match ) declare -p da i recomment u dont set -e On Fri, Apr 23, 2021, 16:43 john wrote: > From: john > To: bug-bash@gnu.org > Subject: ls dumps bash > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: l

Re: bug report

On Fri, Apr 23, 2021 at 10:43 AM john wrote: > From: john > To: bug-bash@gnu.org > Subject: ls dumps bash > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt

bug report

From: john To: bug-bash@gnu.org Subject: ls dumps bash Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin

Re: Bug Report concerning backslash in bash5

Robert Elz writes: > Neither I suspect, Dale just didn't notice which backslashes Ralph > meant were the problem - the one in the expansion of $BLA was never > it, it is the others that appeared - which is an obvious bug > (probably something trivial) which I would expect will be quickly fixed. Y

Re: Bug Report concerning backslash in bash5

On 7/29/20 4:39 AM, Robert Elz wrote: > Date:Tue, 28 Jul 2020 22:41:52 -0400 > From:Eli Schwartz > Message-ID: <4099319f-bc5e-a2ef-cfe8-6189df5a4...@archlinux.org> > > | I'm not sure what point you're trying to make here. Are you arguing that > | *printing* these

Re: Bug Report concerning backslash in bash5

On 7/28/20 6:42 PM, Ralph Beckmann wrote: > Hello GNU team, > > I found this misbehaviour in Bash 5 (e.g. GNU bash, version > 5.0.16(1)-release (x86_64-pc-linux-gnu)): > > $ BLA="1\.2"; echo 'x/'$BLA'/y/' > \x/1\.2/\y/ > > I don't see any reasonable reason for the generated backslashes here. Th

Re: Bug Report concerning backslash in bash5

Date:Tue, 28 Jul 2020 22:41:52 -0400 From:Eli Schwartz Message-ID: <4099319f-bc5e-a2ef-cfe8-6189df5a4...@archlinux.org> | I'm not sure what point you're trying to make here. Are you arguing that | *printing* these backslash escapes is valid behavior here, and the

Re: Bug Report concerning backslash in bash5

On 7/29/20 1:35 AM, Dale R. Worley wrote: > Ralph Beckmann writes: >> I found this misbehaviour in Bash 5 (e.g. GNU bash, version >> 5.0.16(1)-release (x86_64-pc-linux-gnu)): >> >> $ BLA="1\.2"; echo 'x/'$BLA'/y/' >> \x/1\.2/\y/ >> >> I don't see any reasonable reason for the generated backslashe

Re: Bug Report concerning backslash in bash5

Ralph Beckmann writes: > I found this misbehaviour in Bash 5 (e.g. GNU bash, version > 5.0.16(1)-release (x86_64-pc-linux-gnu)): > > $ BLA="1\.2"; echo 'x/'$BLA'/y/' > \x/1\.2/\y/ > > I don't see any reasonable reason for the generated backslashes here. My guess is that you're running into the f

Bug Report concerning backslash in bash5

Hello GNU team, I found this misbehaviour in Bash 5 (e.g. GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)): $ BLA="1\.2"; echo 'x/'$BLA'/y/' \x/1\.2/\y/ I don't see any reasonable reason for the generated backslashes here. Compare to bash 4 (e.g. GNU bash, version 4.4.12(1)-release

Re: Follow-up on PROMPT_COMMAND bug report (submitted today)

On 4/15/20 2:44 PM, Chet Ramey wrote: > On 4/15/20 11:45 AM, Franklin, Jason wrote: >> Greetings: >> >> I realized that I didn't include my email when I used bashbug to report >> my issue, so I'm sending a follow-up email so that the maintainers can >> be

Re: Follow-up on PROMPT_COMMAND bug report (submitted today)

On 4/15/20 11:45 AM, Franklin, Jason wrote: > Greetings: > > I realized that I didn't include my email when I used bashbug to report > my issue, so I'm sending a follow-up email so that the maintainers can > be in touch. I didn't see any bug report. Maybe resend it

Follow-up on PROMPT_COMMAND bug report (submitted today)

Greetings: I realized that I didn't include my email when I used bashbug to report my issue, so I'm sending a follow-up email so that the maintainers can be in touch. I browsed the code and tried to fix the issue myself by modifying the "prompt_again()" function to execute PROMPT_COMMAND directly

Re: bug-report: debug trap messes up pipestatus if containing command substitution

Thanks for the fix! +Shaoyi Peng +端端 On Tue, May 28, 2019, 6:07 PM Chet Ramey wrote: > On 5/23/19 5:11 PM, Hengyang Zhao wrote: > > Awesome! Could you please cc the fix to this thread once it's done? > Thank you! > > It's in the devel branch. I've attached the relevant piece. > > This is mor

Re: bug-report: debug trap messes up pipestatus if containing command substitution

On 5/23/19 5:11 PM, Hengyang Zhao wrote: > Awesome! Could you please cc the fix to this thread once it's done? Thank you! It's in the devel branch. I've attached the relevant piece. This is more confirmation that it was a mistake to apply the DEBUG trap to simple commands in pipelines. -- ``Th

Re: bug-report: debug trap messes up pipestatus if containing command substitution

Awesome! Could you please cc the fix to this thread once it's done? Thank you! Hengyang On Wed, May 22, 2019, 7:27 AM 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 > >

Re: bug-report: debug trap messes up pipestatus if containing command substitution

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

Re: bug-report: debug trap messes up pipestatus if containing command substitution

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

Re: bug-report: debug trap messes up pipestatus if containing command substitution

I missed a segment of my config when copy-pasting: Bash Version: 5.0 Patch Level: 7 Release Status: release On Mon, May 20, 2019 at 9:57 PM Hengyang Zhao wrote: > +speng...@ucr.edu +yunduan@gmail.com > > On Mon, May 20, 2019 at 9:51 PM Hengyang Zhao > wrote: > >> Dear bash developers, >> >

Re: bug-report: debug trap messes up pipestatus if containing command substitution

+speng...@ucr.edu +yunduan@gmail.com On Mon, May 20, 2019 at 9:51 PM 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() { >

bug-report: debug trap messes up pipestatus if containing command substitution

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 | false | true | false echo ${PIPESTATUS[@]} # expects 1 0 1 0 1

Re: bug report

Forwarding to the mailing list. On Wed, Dec 21, 2016 at 07:12:46AM +, Hossein Vatani wrote: > Hi,many thanks for your quick feedback.I tried many tricks, let me give more > explain.assume my password is:  e'r"d`fg!wsif i put it in single > qoutation('e'r"d`fg!ws') there are three single quot

Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

thank you for your answers, i reported such bug to the bash-completion package holder. Regards. On 20-12-2016 18:29, Chet Ramey wrote: On 12/20/16 1:24 PM, Eduardo Bustamante wrote: I cannot reproduce this on bash 4.4: They probably have something defined as the default completer using `com

Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

On 12/20/16 1:24 PM, Eduardo Bustamante wrote: > I cannot reproduce this on bash 4.4: They probably have something defined as the default completer using `complete -D', and that probably tries to add a compspec for it by blindly sticking `command' in front of the word to be completed. -- ``The l

Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

I cannot reproduce this on bash 4.4: dualbus@yaqui:~$ { for i in '-i' '\t' '\t' '\t' '\n' 'exit\n'; do sleep 1; printf -- "$i"; done } | script --command 'bash --norc --noprofile' Script started, file is typescript bash-4.4$ -i bash: -i: command not found bash-4.4$ exit exi

Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

I was running it on a Ubuntu 14.04 LTS machine; the bug occurred when i inputed $ -i and i proceeded with a TAB and it returned this: $ -i bash: complete: -i: invalid option complete: usage: complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action] [-G globpat] [-W wordlist] [-F f

Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

I was running it on a Ubuntu 14.04 LTS machine; the bug occurred when i inputed $ -i and i proceeded with a TAB and it returned this: $ -i bash: complete: -i: invalid option complete: usage: complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action] [-G globpat] [-W wordlist] [-F func

Re: bug report

On Tue, Dec 20, 2016 at 12:39:12PM +, Hossein Vatani wrote: > Hi experts,I encountered a issue that i guessed a bug.i tried to make bash > script that generate strong password and save it with htpasswd command.if i > generate er"exc'oti!ot  for password, i could not send it as string to > ht

bug report

Hi experts,I encountered a issue that i guessed a bug.i tried to make bash script that generate strong password and save it with htpasswd command.if i generate er"exc'oti!ot  for password, i could not send it as string to htpasswd and more strong, in command line i has this problem too."-bash: !

Re: bash-4.3 bug report

On Apr 14, 2014 11:52 AM, "Dave Rutherford" wrote: > > On Mon, Apr 14, 2014 at 12:22 PM, David Binderman wrote: > > Anyone experienced looking at the code will always need to examine it > > more closely to find out why it's a good idea in this case to use an array > > index and *then* sanity chec

Re: bash-4.3 bug report

On Mon, Apr 14, 2014 at 12:22 PM, David Binderman wrote: > Anyone experienced looking at the code will always need to examine it > more closely to find out why it's a good idea in this case to use an array > index and *then* sanity check it's value. But in this case it's a limiting check, not a b

Re: bash-4.3 bug report

On 04/14/2014 10:22 AM, David Binderman wrote: > Hello there, > > >> But my point remains to the original poster: a patch >> without justification is unlikely to be applied. Document WHY you think >> the existing code is a bug, not just HOW to fix it, for y

RE: bash-4.3 bug report

Hello there, > But my point remains to the original poster: a patch > without justification is unlikely to be applied. Document WHY you think > the existing code is a bug, not just HOW to fix it, for your patch to be > usefully considered. Standard softwar

Re: bash-4.3 bug report

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/14/14, 11:19 AM, Eric Blake wrote: > On 04/14/2014 08:50 AM, Chet Ramey wrote: >> On 4/14/14, 5:34 AM, David Binderman wrote: >>> Hello there, >>> >>> [bind.c:2238]: (style) Array index 'j' is used before limits check. >>> >>> Source code is >>>

Re: bash-4.3 bug report

On 04/14/2014 09:35 AM, Andreas Schwab wrote: > Eric Blake writes: > >> In that case, the index check is dead code, > > No. You don't understand. Fair enough. But my point remains to the original poster: a patch without justification is unlikely to be applied. Document WHY you think the exist

Re: bash-4.3 bug report

Eric Blake writes: > In that case, the index check is dead code, No. You don't understand. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: bash-4.3 bug report

On 04/14/2014 09:26 AM, Andreas Schwab wrote: > Eric Blake writes: > >> It silences static code checkers and avoids undefined C behavior. >> >> Also, if invokers[] is allocated such that it ends on the end of a page >> boundary (such as might be the case under certain malloc debuggers), >> then d

Re: bash-4.3 bug report

On 04/14/2014 08:50 AM, Chet Ramey wrote: > On 4/14/14, 5:34 AM, David Binderman wrote: >> Hello there, >> >> [bind.c:2238]: (style) Array index 'j' is used before limits check. >> >> Source code is >> >> for (j = 0; invokers[j] && j < 5; j++) >> >> Suggest new code >> >> for (

Re: bash-4.3 bug report

Eric Blake writes: > It silences static code checkers and avoids undefined C behavior. > > Also, if invokers[] is allocated such that it ends on the end of a page > boundary (such as might be the case under certain malloc debuggers), > then doing the bounds check first will avoid an out-of-bounds

Re: bash-4.3 bug report

On 4/14/14, 5:34 AM, David Binderman wrote: > Hello there, > > [bind.c:2238]: (style) Array index 'j' is used before limits check. > > Source code is > > for (j = 0; invokers[j] && j < 5; j++) > > Suggest new code > > for (j = 0; (j < 5) && (invokers[j] != NULL); j++) Can

bash-4.3 bug report

Hello there,  [bind.c:2238]: (style) Array index 'j' is used before limits check. Source code is   for (j = 0; invokers[j] && j < 5; j++) Suggest new code   for (j = 0; (j < 5) && (invokers[j] != NULL); j++) Regards David Binderman

Re: readline 6.3 bug report

On 3/7/14 2:25 AM, Daan van Rossum wrote: > Hi Chet, > > Readline 6.3 has a new bug in vi-mode: > the "." command does no longer redo the latest "dw", "dl", "D", ... commands. > > Reverting back to version 6.2 fixed the issue for me. Thanks for the report. It's the result of an overzealous atte

Re: Bug report command "cd"

On 4 July 2013 00:08, Chris Down wrote: > Greetings. > > On 3 July 2013 17:52, Stephan van Ingen wrote: >> stephanbosal@in-laptop3:~/Downloads/Win8$ *cd --SMSBOOT-sources-/* >> bash: cd: --: invalid option >> cd: usage: cd [-L|[-P [-e]]] [dir] >> stephanbosal@in-laptop3:~/Downloads/Win8$ *cd \-\-

Re: Bug report command "cd"

Greetings. On 3 July 2013 17:52, Stephan van Ingen wrote: > stephanbosal@in-laptop3:~/Downloads/Win8$ *cd --SMSBOOT-sources-/* > bash: cd: --: invalid option > cd: usage: cd [-L|[-P [-e]]] [dir] > stephanbosal@in-laptop3:~/Downloads/Win8$ *cd \-\-SMSBOOT-sources-/* > bash: cd: --: invalid option

Re: Bug report command "cd"

On Wed, Jul 3, 2013 at 12:52 PM, Stephan van Ingen wrote: > Hello, > > I hope this is the correct way to report a bug (as explained > here > ). > > *The version number of Bash*: 4.2.45(1)-release (x86_64-pc-linux-gnu) > *The ha

Re: Bug report command "cd"

On 07/03/2013 03:52 AM, Stephan van Ingen wrote: > Hello, > > I hope this is the correct way to report a bug (as explained > here Yes. However, what you are reporting is not a bug, but a usage issue on your part. > stephanbos

Bug report command "cd"

Hello, I hope this is the correct way to report a bug (as explained here ). *The version number of Bash*: 4.2.45(1)-release (x86_64-pc-linux-gnu) *The hardware and operating system*. Laptop System76 Intel® Core™ i7-3610QM CPU

Re: bug-report/request: allow "set +n" to re-enable commands.

For 1, use a heredoc to a noop. Sorry for the terse reply, on my phone. On 23 Mar 2013 05:07, "Richard Neill" wrote: > Dear All, > > Might I suggest/request that "set +n" should undo the effect of > "set -n" ? > > For example: > > #!/bin/bash > echo one > set -n >

bug-report/request: allow "set +n" to re-enable commands.

Dear All, Might I suggest/request that "set +n" should undo the effect of "set -n" ? For example: #!/bin/bash echo one set -n echo two set +n echo three would print: one three Here's why I think it would be useful: 1. Bash do

Re: crash bug report, plus complaint about bashbug

On 4/19/12 8:26 AM, Peter Maloney wrote: > Dear bash guys, > > Bashbug interface was COMPLETELY useless. The emacs quit key didn't work. > There were no instructions. It didn't even tell me it was emacs so I could > go look it up. I had to find that out elsewhere. Eventually it wouldn't > even let

crash bug report, plus complaint about bashbug

Dear bash guys, Bashbug interface was COMPLETELY useless. The emacs quit key didn't work. There were no instructions. It didn't even tell me it was emacs so I could go look it up. I had to find that out elsewhere. Eventually it wouldn't even let me edit, saying the buffer is read only. What th

Re: Bug report

On Thu, Nov 11, 2010 at 03:45:08PM -0500, sworddrag...@aol.com wrote: > Description: > It is possible to make input with the keyboard before bash is fully > initialized. This problem is critical on password inputs like the linux login. Bash has nothing to do with accepting passwords durin

Re: Bug report

sworddrag...@aol.com wrote: Description: It is possible to make input with the keyboard before bash is fully initialized. This problem is critical on password inputs like the linux login. Repeat-By: $input is now shown before and after sworddra...@ubuntu:~$. Example: testsworddra...@u

Bug report

From: sworddragon To: bug-bash@gnu.org,b...@packages.debian.org Subject: Input before initializing Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTY

Re: not a bug report but need help

On 10/8/08, naruto canada <[EMAIL PROTECTED]> wrote: > hi > > (I've asked on comp.unix.shell but got no real help) > > anyone have any idea on how to achieve this -- > I'm facing a very stubborn "configure" file that I spend all day try > to modify, but to avail... > anyway, all I need to do is to

not a bug report but need help

hi (I've asked on comp.unix.shell but got no real help) anyone have any idea on how to achieve this -- I'm facing a very stubborn "configure" file that I spend all day try to modify, but to avail... anyway, all I need to do is to replace every call to gcc -La1 -La2 ... -Ib1 -Ib2 ... to gcc -La2 -

Re: bash autocompletion bug report (unable to send via bashbug)

Shriramana Sharma wrote: > Hello. > > Here's the bug report that bashbug was unable to send because it did not > find something called rmail on my system. I hope these bugs can be fixed. Thanks for the report. The bash completion system is developed and distributed separate

bash autocompletion bug report (unable to send via bashbug)

Hello. Here's the bug report that bashbug was unable to send because it did not find something called rmail on my system. I hope these bugs can be fixed. Sincerely, Shriramana Sharma. From: Shriramana Sharma <[EMAIL PROTECTED]> To: bug-bash@gnu.org,[EMAIL PROTECTED] Subject: Vario

echo expansion and POSIX compatibility RFE; bug report

Might I put forth a suggestion? I would like to suggest that the "0" be required after a "\" when expanding octal or hex values. It would be consistent to allow hex values by using "\0xHH", but it is confusingto POSIX compatible scripts for "\1" to be accepted as an octal sequence. Perhaps the

Re: readline5 bug report

Chet: A month ago I sent you this mail reporting a problem with readline 5.0. I did not archive your reply, but I recall you said it would be fixed "in the next release of readline." Now I have tested readline 5.1, and I find that this behavior is unchanged. Is there anything I can do to help s

readline5 bug report

Here is an apparent bug in readline 5.0 as exposed on Fedora Core 4. bash and the readline library both show the bug; readline 4 (also shipped with FC4) does NOT show the incorrect behavior. I built the 5.0 from source from your web site, including 5 patches, and it also shows the bug. What I'm t