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

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

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

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

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

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() { >

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

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

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

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 >

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