Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

| I suspect this is the result your | programmable completion specification for `cat' produces. I suspect it is more likely that the readline config option "match-hidden-files" is "on" (which seems to be its default). Good catch; I have that disabled in my environment. -- ``The lyf s

Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

Date:Fri, 25 Apr 2025 15:44:47 -0400 From:Chet Ramey Message-ID: <9d1a2482-d47f-4c49-9581-45c5db81d...@case.edu> | I can't reproduce this using bash-5.2.37. I can. | I suspect this is the result your | programmable completion specification for `cat' produces.

Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

Thanks, I'll check it out. On Sat, 26 Apr 2025, 1:14 am Chet Ramey, wrote: > On 4/25/25 11:18 AM, Tanmay Jagtap wrote: > > *Dear Bash Maintainers,* > > > > I have encountered an issue with Bash autocompletion on my system. > > Specifically, a file beginning with three dots (e.g., ...Hiding-From-

Re: Bug in Bash Autocompletion: Hidden File, ...Hiding-From-You, Autocompleted Without Dot Prefix

On 4/25/25 11:18 AM, Tanmay Jagtap wrote: *Dear Bash Maintainers,* I have encountered an issue with Bash autocompletion on my system. Specifically, a file beginning with three dots (e.g., ...Hiding-From-You) is autocompleted even when no dot (.) has been typed, which seems inconsistent with typi

Re: Bug: please document extended and alternate for loop syntax

On Mon, Mar 10, 2025 at 5:39 PM Zachary Santer wrote: > > Another alternative would be for bash to print a warning whenever it > encounters this syntax. > Don't do that, the one who don't care about shell portability. i.e the script started with #!/bin/bash may well be using this construct "for

Re: Bug: please document extended and alternate for loop syntax

On 3/10/25 9:38 AM, John Wiersba wrote: Maybe a comment in the documentation along the lines of:     There are also alternate, deprecated syntactic constructs for these loops     which will not be documented here would serve both aims? How is that better? It leads to the inevitable "well,

Re: Bug: please document extended and alternate for loop syntax

On Mon, Mar 10, 2025 at 10:54 AM John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: > > 2) However, if the alternate syntax is actively supported, then I think it > *should* be documented, even if it is considered error-prone and if > "best-practice" is to avoid it. > The alterna

Re: Bug: please document extended and alternate for loop syntax

On Tue, 11 Mar 2025, 00:54 John Wiersba via Bug reports for the GNU Bourne Again SHell, wrote: > The alternative is to have people, like me, stumbling on this > undocumented syntax and spending a considerable amount of time trying to > explore what it is and why it is undocumented. Hah! That's

Re: Bug: please document extended and alternate for loop syntax

On Monday, March 10, 2025, John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: > > The alternative is to have people, like me, stumbling on this > undocumented syntax and spending a considerable amount of time trying to > explore what it is and why it is undocumented. > And how is

Re: Bug: please document extended and alternate for loop syntax

I guess we could approach this topic a different way (the statements below are  just my guesses and not based on any particular insight I have into the history  of this syntax): 1) If this alternate syntax is not actively supported, then that could be stated as the reason why it is not (further)

Re: Bug: please document extended and alternate for loop syntax

On Monday, March 10, 2025 at 12:38:38 PM EDT, Zachary Santer wrote: > Another alternative would be for bash to print a warning whenever it > encounters this syntax. There are precedents for this kind of behavior in languages like perl which issue warnings for deprecated features for several rel

Re: Bug: please document extended and alternate for loop syntax

On Mon, Mar 10, 2025, at 12:38 PM, Zachary Santer wrote: > There are other weird, undocumented things that you could have the > same conversation about. ${#@} is equivalent to ${#} This is documented and not at all weird. $# came from Bourne, and ${#@} is a logical extension of ${#var} that happe

Re: Bug: please document extended and alternate for loop syntax

Thanks, Chet!   Yes, you're right that zsh definitely does not encourage use of these non-standard constructs. This whole thread got started when I accidentally created a mashup of shell/perl, similar to:      for (( i=0; i<3; ++i )) { echo $i; } and was really quite surprised to find that i

Re: Bug: please document extended and alternate for loop syntax

On 3/7/25 12:23 PM, John Wiersba wrote: You're discouraging it's use by not documenting it.  BTW, according to those links below, apparently zsh documents it (and encourages its use)? I think "encourages" is a very generous reading of "These are non-standard and are likely not to be obvious ev

Re: Bug: please document extended and alternate for loop syntax

On Fri, Mar 7, 2025, at 12:23 PM, John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: > You're discouraging it's use by not documenting it. That is the point, I believe. > BTW, according to those links below, apparently zsh documents it This is true. https://zsh.sourceforge.io/D

Re: Bug: please document extended and alternate for loop syntax

Thanks, Greg!!! On Friday, March 7, 2025 at 01:19:28 PM EST, Greg Wooledge wrote: On Fri, Mar 07, 2025 at 17:23:57 +, John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: >    - Is our conversation being recorded somewhere in the gnu archives, so >that I can link to

Re: Bug: please document extended and alternate for loop syntax

On Fri, Mar 07, 2025 at 17:23:57 +, John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: >- Is our conversation being recorded somewhere in the gnu archives, so > that I can link to it in my stackoverflow question?  Otherwise, I'll just > clip quotes from it to paste there.

Re: Bug: please document extended and alternate for loop syntax

Thanks for your reply, Chet!  You're discouraging it's use by not documenting it.  BTW, according to those links below, apparently zsh documents it (and encourages its use)?  Two questions: - Is there a link to some page where you document obsolete/discouraged/deprecated constructs?

Re: Bug: please document extended and alternate for loop syntax

On 3/7/25 9:23 AM, John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: In all versions of bash since 2001 (e.g. 5.1.16(1)-release), the following syntax works but is not documented:$ for (( i=0; i<3; ++i )) { echo $i; } 0 1 2 The group command as loop body syntax only exists for

Re: bug related to "set -e", "&&" and exit codes

On Tue, Feb 11, 2025, at 9:18 AM, Greg Wooledge wrote: > Look at the definition of set -e: > > -e Exit immediately if a pipeline (which may consist of a > single simple command), a list, or a compound command > (see SHELL GRAMMAR abov

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sun, 9 Feb 2025 08:52:07 -0500 From:Greg Wooledge Message-ID: <20250209135207.gn29...@wooledge.org> | Oh, that must be another 2024 change. As my earlier correction indicated, it didn't happen. It turns out that all the *ash shells (bash, yash, and all derive

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 12:30:33 +0700, Robert Elz wrote: > | and "read -p" for the prompt. > > which could be just a printf without a trailing \n before the > read -- but doesn't need to be as read -p is in the standard. Oh, that must be another 2024 change. The manpages-posix package I've go

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sun, 09 Feb 2025 12:30:33 +0700 From:Robert Elz Message-ID: <16760.1739079...@jacaranda.noi.kre.to> | read -- but doesn't need to be as read -p is in the standard. I was sure that had been added, but as usual when I am relying on memory I was wrong, -p isn't i

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sat, 8 Feb 2025 19:33:10 -0500 From:Greg Wooledge Message-ID: <20250209003310.gm29...@wooledge.org> | You really want bash's ${var//search/replace} feature for the | renaming step, In some cases I might agree, not necessarily about the mechanism, but about d

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 06:35:38 +0700, Robert Elz wrote: > ps: there is almost never a good excuse to use non-standard sh > extensions (bash's, or any other shells), when writing a standard > conforming script would allow any Bourne shell variant to > work, and that's certainly the case here, and

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

Date:Sat, 8 Feb 2025 12:08:10 -0500 From:Greg Wooledge Message-ID: <20250208170810.gl29...@wooledge.org> | OK, I think you have something like this: | | while read -r f; do | if [[ $f = *[[:space:]]* ]]; then | read -r -p "Fix <$f>? " yn |

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On 2/8/25 10:48 AM, carlyle_moul...@optusnet.com.au wrote: Then follows a while read REPLY; do # loop to read records from /tmp/$USER/tempfile1 # The first record is discarded, from the remainder the File_Name is extracted and passed to a functionas a quoted string to function File_Contains_Blan

Re: Bug in bash read builtin, info from while read REPLY leaking into separate red -r -p "$1" command in function

On Sun, Feb 09, 2025 at 02:48:42 +1100, carlyle_moul...@optusnet.com.au wrote: > I have a script to go through file names in the current directory, > check whether they contain blanks and optionally replace blanks with > underscores. for f in *[[:space:]]*; do read -r -p "Fix <$f>? " yn if

Re: bug-bash Digest, Vol 265, Issue 40

On Fri, 20 Dec 2024 08:09:40 -0500, Greg Wooledge wrote: > Assuming you meant -d not -c: Good eye. > Why did you expect them to be the same? A surprisingly hard question. Um, well, this report was from something I noticed a few months ago. As I recall, `help -d '('` returns information about

Re: [bug #66460] A documentation correction regarding an array nameref???

On 11/20/24 4:48 AM, Wiley Young wrote: "The nameref attribute cannot be applied to array variables." Some thoughts on English language Perhaps "attribute" could be more explicitly defined? ...as something like, 'a characteristic [ given to | assigned to | applied to | associated with | d

Re: [bug #66460] A documentation correction regarding an array nameref???

Today's Topics: > >1. Re: redirection / process substitution fails to read a file > descriptor (Chet Ramey) >2. Re: history-search-* and undo lists (Grisha Levit) >3. Re: [PATCH] lib/readline/doc makefiles clean targets > (Grisha Levit) >4. [bug #66

Re: [bug #66460] A documentation correction regarding an array nameref???

On Tue, Nov 19, 2024 at 01:40:12AM -0500, Harry Clauson wrote: > URL: > > > Summary: A documentation correction regarding an array > nameref??? >Group: The GNU Bourne-Again SHell >Submitter: harryc >

Re: [bug #66455] declare -p [varname] does not recognize nameref variables

On Mon, Nov 18, 2024 at 07:39:31 -0500, Dominik Kummer wrote: > > > Summary: declare -p [varname] does not recognize nameref > variables Hmm? hobbit:~$ declare -n ref=HOME hobbit:~$ declare -p ref declare -n ref="HOME"

Re: bug-bash Digest, Vol 264, Issue 28

On Sunday, November 17, 2024, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > > recondite > That's a recondite word, isn't it Sunday where you live? -- Oğuz

Re: bug-bash Digest, Vol 264, Issue 31

digest..." > > > Today's Topics: > >1. redirection / process substitution fails to read a file > descriptor (Mike Peters) >2. Re: redirection / process substitution fails to read a file > descriptor (Greg Wooledge) >3. Re: bug-bash Digest,

Re: bug-bash Digest, Vol 264, Issue 28

At 2024-11-16T18:52:12-0800, Wiley Young wrote: > | From: Martin D Kealey > > | "In the general case I agree; man > > | pages should be reference > > | manuals, not tutorials" > > We should value others' contributions. This statement implies that we lack a means of evaluating contribut

Re: bug-bash Digest, Vol 264, Issue 28

| From: Martin D Kealey | "In the general case I agree; man | pages should be reference | manuals, not tutorials" We should value others' contributions. Most people, when they read something that they don't yet understand, if they wish to understand it, will seek out a more accessible

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 #66068] built-in printf function not working with float

On 8/6/24 5:58 AM, anonymous wrote: jesusm@liet:[~]$ bash --version GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu) Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are fre

Re: [bug #66068] built-in printf function not working with float

On Tue, Aug 06, 2024 at 05:58:56 -0400, anonymous wrote: > jesusm@liet:[~]$ bash --version > GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu) > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This

Re: [Bug] Array declaration only includes first element

On Thu, Jul 18, 2024, at 8:57 AM, Greg Wooledge wrote: > $a is equivalent to ${a[0]}. This is documented, by the way. It is not a bug. "Referencing an array variable without a subscript is equivalent to referencing with a subscript of 0." https://www.gnu.org/software/bash/manual/html_node/Arra

Re: [Bug] Array declaration only includes first element

On Thu, Jul 18, 2024 at 00:00:17 +, Charles Dong via Bug reports for the GNU Bourne Again SHell wrote: > - Declare an array: `a=(aa bb cc dd)` > - Print this array: `echo $a` or `printf $a` $a is equivalent to ${a[0]}. That's not how you print an entire array. The easiest way to print an ar

Re: [bug #65981] "bash test -v" does not work as documented with "export KEY="

Date:Sat, 13 Jul 2024 08:57:18 +0200 From:Andreas =?iso-8859-1?B?S+Ro5HJp?= Message-ID: | After the "export", the variable has been *set*. That's right, but there's no point answering that message here, the anonymous poster will almost certainly never see it. Law

Re: [bug #65981] "bash test -v" does not work as documented with "export KEY="

On Fri, Jul 12, 2024 at 10:15:02PM -0400, anonymous wrote: > URL: > > > Summary: "bash test -v" does not work as documented with > "export KEY=" >Group: The GNU Bourne-Again SHell >Submitter: None >

Re: Bug tracking

On Tue, 2 Apr 2024 at 00:31, Chet Ramey wrote: > On 3/31/24 8:34 PM, Martin D Kealey wrote: > > That's a good start, but it seems incomplete, and there's little -- > perhaps > > no -- overlap with bug reports in this list. > And this is still the most fundamental problem; the submission of bug r

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

On 6/3/24 08:30, Chet Ramey wrote: On 6/2/24 9:43 AM, Brett Neumeier wrote: ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu --enable-static-link --without-bash-malloc I get this failure: [...] If I add "#include " to tparam.c, it bui

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

On 6/2/24 9:43 AM, Brett Neumeier wrote: ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu --enable-static-link --without-bash-malloc I get this failure: --- aarch64-cbl-linux-gnu-gcc -c -I/home/lbl/work/sysroot/scaffolding/include -DHAVE_CONFIG_H -I. -I../.. -I../

Re: bug in bash

On 5/14/24 11:12 AM, Chet Ramey wrote: On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to

Re: bug in bash

On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to kill a procsub when you interrupt the j

Re: bug in bash

On Mai 14 2024, Chet Ramey wrote: > Setting the process group might solve this particular issue, at the cost of > losing keyboard-generated signals. That's not so bad for SIGINT, though > people do expect to be able to kill a procsub when you interrupt the job > using it, but you also wouldn't be

Re: bug in bash

On 5/13/24 3:37 PM, Oğuz wrote: On Monday, May 13, 2024, Chet Ramey > wrote: performs the setpgid in the process forked to run the process substitution). Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout

Re: bug in bash

On Monday, May 13, 2024, Chet Ramey wrote: > performs the setpgid in the process forked > to run the process substitution). > Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout? Direct it from /dev/null? -- Oğuz

Re: bug in bash

On 5/12/24 10:00 AM, Oğuz wrote: On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: Since the redirection fails and the cat command is never started, bash doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553 execve("/usr/bin/w

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > Ah... I assumed bk was an existing file. > > hobbit:~$ cat <(wc -l) <.bashrc > wc: 'standard input': Input/output error > 0 > hobbit:~$ Even then there can be a race when the foreground command finishes fast enough that bash switches the terminal process gr

Re: bug in bash

On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: > Since the redirection fails and the cat command is never started, bash > doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553 execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10

Re: bug in bash

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote: > > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > >> I found a bug when i tried with syntax <(cmd). this is an example > >> cat <(wc -l) < bk > Since the redirection fails and the cat command is never started, bash >

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: >> I found a bug when i tried with syntax <(cmd). this is an example >> cat <(wc -l) < bk > > What is "wc -l" supposed to read from? It counts lines of standard input, > until EOF is reached. But

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk What is "wc -l" supposed to read from? It counts lines of standard input, until EOF is reached. But its standard input is a terminal. And you're r

Re: bug in bash

On Sun, 12 May 2024 03:55:21 +0200 Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside in the parenthesis and the main process

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside in the parenthesis and the main pro

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 4/28/24 6:18 PM, Gioele Barabucci wrote: On 28/04/24 22:50, Chet Ramey wrote: On 4/28/24 3:07 PM, Gioele Barabucci wrote: $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static -bash-stati

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 28/04/24 22:50, Chet Ramey wrote: On 4/28/24 3:07 PM, Gioele Barabucci wrote: $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static -bash-static So argv[0] == "-bash-static", which cause

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 4/28/24 3:07 PM, Gioele Barabucci wrote:     $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo'     /bin/bash     /usr/bin/bash-static     -bash-static So argv[0] == "-bash-static", which causes $0 to be set to -bash-static and int

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 28/04/24 20:01, Chet Ramey wrote: On 4/27/24 6:23 PM, Gioele Barabucci wrote: bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash-stat

Re: [bug #65651] argument reference inconsistency

On 4/28/24 1:10 PM, Lawrence Velázquez wrote: On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote: I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Apparently it's not possible to have the replies

Re: [bug #65651] argument reference inconsistency

On 4/28/24 7:59 AM, Emanuele Torre wrote: I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Because savannah can't do that. The original request was to have one place to go to for bug reports. The best

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote: > I don't know why this savannah ticket has been crossposted to @bug-bash, > but its replies have not been crossposted here: it is very confusing. Apparently it's not possible to have the replies crossposted: https://savannah.gnu.org/support

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, 13:59 Emanuele Torre wrote: > I don't know why this savannah ticket has been crossposted to @bug-bash, > but its replies have not been crossposted here: it is very confusing. > cool , thanks ... btw got me the link ? thxx && bless Anyway, they already got a response on sav

Re: [bug #65651] argument reference inconsistency

I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Anyway, they already got a response on savannah. o/ emanuele6

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, 08:52 anonymous wrote: > URL: > > > Summary: argument reference inconsistency >Group: The GNU Bourne-Again SHell >Submitter: None >Submitted: Sun 28 Apr 2024 06:51:4

Re: Bug tracking

On 4/1/24 5:30 AM, Koichi Murase wrote: Perhaps bug tracking could be migrated to a more modern system? I think a more realistic solution for GNU is to improve Savane, which is also an open-source project: https://savannah.nongnu.org/projects/administration/ That is a GNU project decision, a

Re: Bug tracking

On 3/31/24 8:34 PM, Martin D Kealey wrote: On Mon, 11 Dec 2023, 05:19 Chet Ramey, > wrote: On 11/30/23 5:18 AM, Martin D Kealey wrote: > If there's a bug tracking system beyond "threads in a mailing list", I'd > like to know how I can get access t

Re: Bug tracking

2024年4月1日(月) 9:35 Martin D Kealey : > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > > On 11/30/23 5:18 AM, Martin D Kealey wrote: > > > If there's a bug tracking system beyond "threads in a mailing list", I'd > > > like to know how I can get access to it. > > > > https://savannah.gnu.org/support

Re: Bug tracking

On Monday, April 1, 2024, Martin D Kealey wrote: > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > Are we building a cathedral with gatekeepers, or a bazaar > where the masses can contribute? > What's stopping masses from contributing now? All you need is an email address. And why this non-st

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: Ligatures are removed as one character

On 2/25/24 5:37 AM, Martin D Kealey wrote: Unicode has categories for "modifiers" (especially "modifier letters") and for "combining characters". Note that each symbol can be in multiple categories. Modifiers change how another character is displayed. They may or may not be considered to have t

Re: Bug: Ligatures are removed as one character

n Fri, 23 Feb 2024, Chet Ramey wrote: > On 2/19/24 9:26 PM, Avid Seeker wrote: > > When pressing backspace on Arabic ligatures (including characters with > > diacritics), they are removed as if they are one character. > > As you might guess, readline doesn't know much about Arabic, per se. In a > U

Re: Bug: Ligatures are removed as one character

On 2/19/24 9:26 PM, Avid Seeker wrote: When pressing backspace on Arabic ligatures (including characters with diacritics), they are removed as if they are one character. As you might guess, readline doesn't know much about Arabic, per se. In a UTF-8 locale, for example, it knows base characters

Re: Bug: Ligatures are removed as one character

$ locale LANG=C.UTF-8 LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL= But it's th

Re: Bug: Ligatures are removed as one character

On 2/19/24 9:26 PM, Avid Seeker wrote: When pressing backspace on Arabic ligatures (including characters with diacritics), they are removed as if they are one character. What's your locale? (Not that I guarantee having it installed.) -- ``The lyf so short, the craft so long to lerne.'' - Chauc

Re: Bug: Ligatures are removed as one character

It's been a long time since I looked into Unicode, but this is what I remember. Depending on the Unicode normalisation level, backspace is *supposed* to remove a letter and all its associated combining marks. The root problem seems to be that some Arabic letters change from "non-combining" to "co

Re: BUG: Here-doc delimiter: unclosed quotes

On 1/18/24 9:16 AM, Dastan Abdygali wrote: Bash Version: 5.2 Patch Level: 0 Release Status: release Description: If unclosed single quotes or unclosed double quotes are used as a delimiter in here-doc, bash lets the user finish the quote on the next lines. As a result delimite

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

On 1/16/24 7:11 PM, Emre Ulusoy wrote: Dear Bash Maintainers, I hope this message finds you well. I am writing to inquire about the possibility of contributing to your project. Recently, I discovered a potential bug in the 'bash --posix' terminal and I believe I have a fix that could resolve

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote: > Recently, I discovered a potential bug in the 'bash --posix' terminal > and I believe I have a fix that could resolve this issue. Before > proceeding, I wanted to confirm if this is an open-source project where > external contributions via p

Re: [bug-bash] Bash-5.2 Patch 22

On 1/16/24 10:09 AM, Dr. Werner Fink wrote: On 2024/01/16 09:27:19 -0500, Chet Ramey wrote: On 1/16/24 4:00 AM, Dr. Werner Fink wrote: what is with the readline82-008, readline82-009, and readline82-010 patches? What about them? Should those be part also of trhe bash52 patches as well? B

Re: [bug-bash] Bash-5.2 Patch 22

On 2024/01/16 09:27:19 -0500, Chet Ramey wrote: > On 1/16/24 4:00 AM, Dr. Werner Fink wrote: > > > what is with the readline82-008, readline82-009, and readline82-010 > > patches? > > What about them? Should those be part also of trhe bash52 patches as well? -- "Having a smoking section in a

Re: [bug-bash] Bash-5.2 Patch 22

On 1/16/24 4:00 AM, Dr. Werner Fink wrote: what is with the readline82-008, readline82-009, and readline82-010 patches? What about them? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@cas

Re: [bug-bash] Bash-5.2 Patch 22

On 2024/01/14 13:34:06 -0500, Chet Ramey wrote: >BASH PATCH REPORT >= > > Bash-Release: 5.2 > Patch-ID: bash52-022 > > Bug-Reported-by: srobert...@peratonlabs.com > Bug-Reference-ID: > Bug-Reference-URL: > https:

Re: Bug in readline when readline-colored-completion-prefix is set

On 11/29/23 11:32 AM, raphaal wrote: Hi all, My version of bash is: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) When the .inputrc contains: > colored-completion-prefix on and LS_COLORS="*.readline-colored-completion-prefix=01;30" then readline ignores the setting and uses defau

Re: BUG: Colorize background of whitespace

On Thursday, October 26, 2023, Phi Debian wrote: > On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge wrote: > > > > > Ahh. That wasn't clear to me. Thanks. > > > > > Ouch got caught the same way. This can be reduced to > > $ clear > $ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n" > $ #

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge wrote: > > Ahh. That wasn't clear to me. Thanks. > > Ouch got caught the same way. This can be reduced to $ clear $ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n" $ # Recall and run prev command repeat the later until top lines scroll out

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 02:48:20PM +, David wrote: > On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > > Repeat-By: > > > run the following command line: > > > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs

Re: BUG: Colorize background of whitespace

On 10/25/23 10:48 AM, David wrote: The bug being reported is that the '\t' characters have a black background if the 'seq' argument is low enough that its lines 1 and 2 remain visible when run. Bash and readline don't do anything with terminal foreground colors and background colors except und

Re: BUG: Colorize background of whitespace

On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > Description: > > The initial bash background is hardcoded to some default (e.g. black) and > > cannot be colorized by printing "transparent" tabs/newlines with > > ANSI-ESC-cod

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > Description: > The initial bash background is hardcoded to some default (e.g. black) and > cannot be colorized by printing "transparent" tabs/newlines with > ANSI-ESC-codes. > Only after a vertical scrollbar appears, the whitespace b

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 11:09 AM Holger Klene wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto > -ffat-lto-objects -fstack-protector-strong -Wformat -

Re: bug in bashbug script shipped with bash 5.2.15

On 10/9/23 1:18 PM, Ti Strga wrote: The bug likely got checked in earlier than 5.2.15, that's just what I happened to be running when I ran into this. Thanks, it's already been fixed in the devel branch. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ar

Re: bug:

On Tue, Oct 03, 2023 at 12:54:45PM +, queency jones via Bug reports for the GNU Bourne Again SHell wrote: > BASH_VERSION='5.1.4(1)-release'PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"no > compile needed > i made a fifo file by typing: mkfifo gdbout.fifo > i coded a resource file named  : comm

Re: bug#65659: RFC: changing printf(1) behavior on %b

Stephane Chazelas wrote in <20230902084912.vdfedsgbnat2w...@chazelas.org>: |2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \ |Open Group: ... |>|FWIW, a "printf %b" github shell code search returns ~ 29k |>|entries |>|(https://github.com/search?q=printf+%25b+language%3

Re: bug#65659: RFC: changing printf(1) behavior on %b

Le 02/09/2023 à 07:46, Phi Debian écrivait : On Fri, Sep 1, 2023 at 8:10 PM Stephane Chazelas wrote: 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: FWIW, a "printf %b" github shell code search returns ~ 29k entries ( https://github.com/search?q=printf+%25b+langua

  1   2   3   4   5   6   7   8   9   10   >