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

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

excluded from completion unless the input starts with a dot. Here’s how to reproduce the issue: # Setup mkdir ~/bash-bug-test cd ~/bash-bug-test touch ...hiddenfile # Now test cat *Expected Behavior:* No suggestions should appear as the input does not start with a dot (.). *Actual Behavior:* The

[bug #67045] bash parsing error, when using readline, backslashes, and

URL: Summary: bash parsing error, when using readline, backslashes, and Group: The GNU Bourne-Again SHell Submitter: None Submitted: Tue 22 Apr 2025 08:41:19 PM UTC Category:

Is this a bug?

Howdy, This system is a Fedora 42 x86_64 system. I've been trying to build bash from a repository "https://git.savannah.gnu.org/git/bash.git"; and a having the devil's own time in the process. Did I just catch the repository in the middle of a rework? I have a full log of the build process if

Re: Is this a bug?

Hi, George R Goffe writes: > I've been trying to build bash from a repository > "https://git.savannah.gnu.org/git/bash.git"; and a having the devil's own time > in the process. > > Did I just catch the repository in the middle of a rework? I have a > full log of the build process if it's neede

[bug #66923] Manual states that $(cat x) and $(< x) being equivalent not strictly true

URL: Summary: Manual states that $(cat x) and $(< x) being equivalent not strictly true Group: The GNU Bourne-Again SHell Submitter: None Submitted: Tue 18 Mar 2025 01:30:06 PM UTC

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"

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. Ha

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. &

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

archives, so >    that I can link to it in my stackoverflow question?  Otherwise, I'll >    just clip quotes from it to paste there. The thread starts here: https://lists.gnu.org/archive/html/bug-bash/2025-03/msg9.html Chet -- ``The lyf so short, the craft so long to lerne.'

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

e. The thread starts here: https://lists.gnu.org/archive/html/bug-bash/2025-03/msg9.html Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~che

Re: Possible bug for nested curly brace expansion

{0} is no expansion {0,} is it must be 2+ On Thu, Mar 6, 2025, 7:40 PM Trond Endrestøl via Bug reports for the GNU Bourne Again SHell wrote: > $ bash --version > GNU bash, version 5.2.37(0)-release (amd64-portbld-freebsd14.1) > Copyright (C) 2022 Free Software Foundation, Inc. > L

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://zs

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 l

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

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

M, 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 o

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 exi

Bug: please document extended and alternate for loop syntax

nux mint virginia (ubuntu jammy) GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)Bug: please document this extended/alternate syntax for the for loop.See also my question at https://unix.stackexchange.com/questions/792066/why-does-this-bash-for-loop-syntax-workand some more information

Re: Possible bug for nested curly brace expansion

On Thu, Mar 6, 2025, at 9:06 PM, Kaz Kylheku wrote: > But Bash cannot do this. The reason is that brace expansion is already > a deviation from POSIX. POSIX.1-2024 does permit brace expansion syntax as an extension, although it doesn't use the term "brace expansion" or prescribe any specific seman

Re: Possible bug for nested curly brace expansion

On 2025-03-06 11:58, Lawrence Velázquez wrote: > On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote: >> {0} is no expansion >> {0,} is >> it must be 2+ > > And this is documented. It is not a bug. > > A correctly-formed brace expansion must contain unq

Re: Possible bug for nested curly brace expansion

On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote: > {0} is no expansion > {0,} is > it must be 2+ And this is documented. It is not a bug. A correctly-formed brace expansion must contain unquoted opening and closing braces, and at least one unquoted comma o

Possible bug for nested curly brace expansion

$ bash --version GNU bash, version 5.2.37(0)-release (amd64-portbld-freebsd14.1) Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change and redistribute it. There is NO WARRANTY,

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

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

   command2 is executed if, and only if, command1 returns an exit status of zero (success). > >        An OR list has the form > >               command1 || command2 > >        command2  is  executed  if,  and only if, command1 returns a non-zero exit status. *The return status of AND and OR lists is

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

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

From: carl To: bug-bash@gnu.org Subject: [50 character or so descriptive subject here (for reference)] In a script two instances of the read builtin mutually interfere Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS

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: String substitution bug

On Mon, Nov 25, 2024 at 9:48 PM Martin D Kealey wrote: > > On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote: >> >> People can write bad code in any language. > > Yeah, that includes English, apparently. > > The problem is that the Shell makes it hard to write good code and easy to > write bad

Re: String substitution bug

On Tue, Nov 26, 2024 at 12:47:48PM +1000, Martin D Kealey wrote: ... > The problem is that the Shell makes it hard to write good code and easy to > write bad code. > > (“No programmer would ever be lazy.” Yeah, right. I ran a tutorial on Bash > at the 2015 LCA in Auckland, and was abashed (pun in

Re: String substitution bug

Writing's more difficult than reading, and writing can be expensive. Synoptic reading, traditionally, is considered the "highest form" of reading (according to "How to Read a Book") (Hate mail to them, please, not me.). Writing from some definable point of view is inevitable. It might be worthwhi

Re: String substitution bug

On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote: > On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey > wrote: > > > > How about this for a concrete proposal: let's split the current man page > > into a page per topic. The following list is alphabetical, though I > should > > probably put it in

Re: String substitution bug

On 11/25/24 3:18 PM, Lawrence Velázquez wrote: I'm not opposed to modest clarification, but mentioning "[[:class:]]" would be misleading because it would give the impression that character class expressions must occur alone within their bracket expressions. I added an example illustrating thi

Re: String substitution bug

On Mon, Nov 25, 2024, at 3:18 PM, Lawrence Velázquez wrote: > $ unset IFS Sorry, this is from an earlier draft in which I used $* to generate the string of space-separated letters. I just forgot to remove it; it isn't relevant for the example I actually sent. -- vq

Re: String substitution bug

On 11/25/24 2:18 PM, marcel.plch wrote: On Monday, November 25th, 2024 at 5:49 PM, Chet Ramey wrote: On 11/23/24 9:29 PM, marcel.plch via Bug reports for the GNU Bourne Again SHell wrote: Thank you for clarifictaion. Maybe adding an extra clarification to the bash manpage in the

Re: String substitution bug

On Mon, Nov 25, 2024, at 2:18 PM, marcel.plch via Bug reports for the GNU Bourne Again SHell wrote: > Not in one place the pattern "[[:space:]]" is mentioned. Why should the "space" character class be called out in particular? It's not special. > If adding just on

Re: String substitution bug

On Monday, November 25th, 2024 at 5:49 PM, Chet Ramey wrote: > On 11/23/24 9:29 PM, marcel.plch via Bug reports for the GNU Bourne Again > SHell wrote: > > > Thank you for clarifictaion. > > > > Maybe adding an extra clarification to the bash manpage > >

Re: String substitution bug

On 11/23/24 9:29 PM, marcel.plch via Bug reports for the GNU Bourne Again SHell wrote: Thank you for clarifictaion. Maybe adding an extra clarification to the bash manpage in the Pattern Matching section would be a good idea? I can add some clarifying text, but I figure that the since this

Re: history bug: new shell separates lines from the history file

gnu.org/archive/html/bug-bash/2015-12/msg00206.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature

Re: String substitution bug

On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey wrote: > > How about this for a concrete proposal: let's split the current man page > into a page per topic. The following list is alphabetical, though I should > probably put it in some kind of narrative order. > >[...] You mostly just reinvent

Re: String substitution bug

On Mon, 25 Nov 2024 at 00:21, Oğuz wrote: > In another document, not the manual. > If my suggested addition does not belong in the manual, then neither does *any* mention of "character class", nor indeed the entire existing description of "regular expression". Please provide a patch that removes

Re: String substitution bug

On Sun, Nov 24, 2024 at 10:51:43PM +1000, Martin D Kealey wrote: > On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote: > > > I think the manual is quite clear: > > > > Within [ and ], character classes can be specified > > using the syntax [:class:], where class is one of the > >

Re: String substitution bug

On Sun, Nov 24, 2024 at 02:58:45PM -0500, Lawrence Velázquez wrote: > On Sun, Nov 24, 2024, at 10:08 AM, Andreas Kähäri wrote: > > On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote: > >> Similar cases exist elsewhere within the man page. For example, if you > >> search for $! or $$ you

Re: String substitution bug

On Mon, 25 Nov 2024 at 01:08, Andreas Kähäri wrote: > I don't agree that the special parameters should be written as $! etc. > since those are their _values_ when used in the shell (exactness is a > virtue in a manual). > In a *printed* manual I would agree with you, but in a man page where the

Re: String substitution bug

On Sun, Nov 24, 2024, at 10:08 AM, Andreas Kähäri wrote: > On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote: >> Similar cases exist elsewhere within the man page. For example, if you >> search for $! or $$ you will not find the section that documents them. >> You would have to know th

Re: String substitution bug

On Sun, Nov 24, 2024 at 7:52 AM Martin D Kealey wrote: > > When one already knows how it works, that's obvious, and it's hard to see > how it could mean anything else. > > When one *doesn't *already know how it works, “using the syntax *[:class:]*” > could just as easily mean using *:class:* insid

Re: String substitution bug

n matching section (as I don't have an issue with the way the text is presented). It may be worth aligning the presentation of the text in the manual with the standard, but I don't think it's a bug as such. > > Another one that commonly trips people up is the ${parameter-w

Re: String substitution bug

On Sun, Nov 24, 2024 at 22:51:43 +1000, Martin D Kealey wrote: > When one *doesn't *already know how it works, “using the syntax *[:class:]*” > could just as easily mean using *:class:* inside *[…]*. Yeah, good luck with that. I predict that if you offer a patch to make this clearer, there will b

Re: String substitution bug

On Sunday, November 24, 2024, Martin D Kealey wrote: > > This REALLY needs to be driven home both in the explanation and with > examples, preferably with at least one that illustrates using more than one > character class inside one match group. > In another document, not the manual. -- Oğuz

Re: String substitution bug

On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote: > I think the manual is quite clear: > > Within [ and ], character classes can be specified > using the syntax [:class:], where class is one of the > following classes defined in the POSIX standard: > alnum alpha

Re: String substitution bug

On Sun, Nov 24, 2024 at 02:29:01AM +, marcel.plch via Bug reports for the GNU Bourne Again SHell wrote: > On Sunday, November 24th, 2024 at 3:05 AM, Lawrence Velázquez > wrote: > > > On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU > > Bou

Re: String substitution bug

On Sunday, November 24th, 2024 at 3:05 AM, Lawrence Velázquez wrote: > On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU > Bourne Again SHell wrote: > > > I am trying to do some file management in bash and I have strings in > > this format: >

Re: String substitution bug

On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU Bourne Again SHell wrote: > I am trying to do some file management in bash and I have strings in > this format: > > 1 dir/hello.txt > 2 dir2/bar.jpg > > When I run this substitution: > ${FOO/[:spac

String substitution bug

escription: I am trying to do some file management in bash and I have strings in this format: 1 dir/hello.txt 2 dir2/bar.jpg When I run this substitution: ${FOO/[:space:]*/Hello} I get this result: 1 dir/hHello The goal is to substitute everything after the first space (including the space) with

Re: history bug: new shell separates lines from the history file

Hello Michael The previously embedded lines (the for loop) now have got a timestamp (the > one from the shell start?)! > This is unwanted behavior, because now a cursor-up brings the separated > lines. > More precisely, any history read from a history file will *not* be in "command-oriented" mode

history bug: new shell separates lines from the history file

Hello, I want to file a bug in bash. 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 -Werror=format-security -Wall

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???

use ] of a parameter' Or possibly it's just something to do with how the various attributes as a group interact? 'Some attributes are mutually exclusive: a parameter marked as an array cannot also [ be marked as a | receive the ] namref (attribute), etc...' 2 cents, Wil

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 >

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

URL: Summary: A documentation correction regarding an array nameref??? Group: The GNU Bourne-Again SHell Submitter: harryc Submitted: Tue 19 Nov 2024 06:40:06 AM UTC Category:

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"

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

URL: Summary: declare -p [varname] does not recognize nameref variables Group: The GNU Bourne-Again SHell Submitter: domson Submitted: Mon 18 Nov 2024 01:39:22 PM CET Category

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

That email I read. :-( On Sat, Nov 16, 2024, 20:58 wrote: > Send bug-bash mailing list submissions to > bug-bash@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/bug-bash > or, via email, send a me

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

[bug #66445] Use after free in change_to_directory function

URL: Summary: Use after free in change_to_directory function Group: The GNU Bourne-Again SHell Submitter: None Submitted: Fri 15 Nov 2024 10:48:54 AM UTC Category: None

[bug #66444] Use after free in expand_string_dollar_quote function

h_single_quote (trans); 4294 else 4295t = sh_mkdoublequoted (trans, translen, 0); 4296 sindex = news; 4297} This is clearly a bug, we have free(t) and in the next instruction the t variable is used directly: 4291 if (singlequote_transl

[bug #66412] Missing space in documentation

URL: Summary: Missing space in documentation Group: The GNU Bourne-Again SHell Submitter: None Submitted: Wed 06 Nov 2024 09:23:39 AM UTC Category: None Severi

[bug #66363] "test" builtin command, -a arg not working as expected

URL: Summary: "test" builtin command, -a arg not working as expected Group: The GNU Bourne-Again SHell Submitter: None Submitted: Mon 21 Oct 2024 10:18:53 AM UTC Category: Non

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 aliase

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

[bug #66234] effect of redirecting stderr on checkwinsize undocumented

URL: Summary: effect of redirecting stderr on checkwinsize undocumented Group: The GNU Bourne-Again SHell Submitter: None Submitted: Fri 20 Sep 2024 03:57:42 AM UTC Category:

[bug #66154] documentation bug about "$?"

URL: <https://savannah.gnu.org/bugs/?66154> Summary: documentation bug about "$?" Group: The GNU Bourne-Again SHell Submitter: shynur Submitted: Sun 01 Sep 2024 04:24:03 AM CST

[bug #66127] [Bash x86] Increased memory bandwidth due to background commands

URL: Summary: [Bash x86] Increased memory bandwidth due to background commands Group: The GNU Bourne-Again SHell Submitter: korantli Submitted: Mon 26 Aug 2024 03:10:18 AM UTC

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

ompiler and fell victim to this: https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html I attached a patch. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.ed

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

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

URL: Summary: built-in printf function not working with float Group: The GNU Bourne-Again SHell Submitter: None Submitted: Tue 06 Aug 2024 09:58:54 AM UTC Category: None

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/man

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

[Bug] Array declaration only includes first element

Hello, I would like to report an unexpected behavior with array declaration on latest Bash, which is very likely to be a bug. I discovered this when I found Pinentry could not display GUI windows properly. - Bash version: 5.2.26(1)-release - OS: Arch Linux (Kernel: 6.9.9-arch1-1) (My PC), and

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 >

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

URL: Summary: "bash test -v" does not work as documented with "export KEY=" Group: The GNU Bourne-Again SHell Submitter: None Submitted: Sat 13 Jul 2024 02:15:01 AM UTC Catego

Re: yet another $(case ... parse bug

Le Thu, May 23, 2024 at 08:19:49PM +0300, Oğuz a écrit : > > $ bash -c 'for (( $(case x in x) esac);; )); do :; done' >From there, I've tested: bash-5.3-alpha$ uname=1 bash-5.3-alpha$ echo $(( uname - $(echo 1) )) 0 bash-5.3-alpha$ echo $(( uname - $(case x in x) echo 1;exit;;esac;echo 0)

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

  1   2   3   4   5   6   7   8   9   10   >