Re: MacOS Homebrew bash '5.3.0(1)-release' breaks 'wait' (?)

On Tue, Jul 15, 2025 at 06:52:14 -0400, Zachary Santer wrote: > On Mon, Jul 14, 2025 at 10:52 PM John Sidles wrote: > >> > >> I was a pretty big part of that discussion, and this looks broken to > >> me. If 'wait -n' is passed a list of pids, it shouldn't also be > >> waiting for other background

Re: parser bug in Q_ARITH

On Wed, Jul 09, 2025 at 11:36:59 -0400, Chet Ramey wrote: > The arithmetic expression within (( and )) is equivalent to > > let "expression" > > so the contents are expanded once as if in double quotes. This has > always been the case -- earlier versions of bash just translated > ((expr)) into le

Re: parser bug in Q_ARITH

On Mon, Jun 30, 2025 at 08:33:49 -0600, Stan Marsh wrote: > It seems to me that there is never any need for $ in arithmetic contexts, so > the > obvious fix would be to just remove any $ found between (( and )). But from > what I > understand that is easier said than done. Unfortunately, that's

Re: Typo in Bash Reference Manual

On Sun, Jun 29, 2025 at 06:39:18 -0600, Stan Marsh wrote: > Note, incidentally, that it is not strictly true that a negative offset has > to be preceded by a space. A zero will work as well. And I think that is > clearer. I.e., instead of: > > # Print the last 2 characters of $HOME > $ echo ${H

Re: Typo in Bash Reference Manual

On Sun, Jun 29, 2025 at 21:51:52 +0700, Robert Elz wrote: > Date:Sun, 29 Jun 2025 08:13:07 -0600 > From:Stan Marsh > Message-ID: > > | So, is this POSIX, or just a dash-extension? > > It is original Bourne Shell (from 7th edition Bell Labs Unix) > and is (or shoul

Re: Typo in Bash Reference Manual

On Wed, Jun 25, 2025 at 17:47:31 +, Wartik, Steven P "Steve" via Bug reports for the GNU Bourne Again SHell wrote: > After many years of staring at the Bash Reference Manual, I just noticed a > typo in Section 3.5.3 (Shell Parameter Expansion): > > [cid:image003.jpg@01DBE5D7.B1DBC120] > > T

Re: set -e doesn't trigger when command substitutions returns, why?

On Wed, Jun 18, 2025 at 04:57:01 +0300, nkkralev--- via Bug reports for the GNU Bourne Again SHell wrote: > to occur.]#test1 > /bin/bash -c 'set -e ; /bin/echo $(ls /doesnt_exist) ; echo print1' > #and the stdout/stderr displayed is: > ls: cannot access '/doesnt_exist': No such file or directorypr

Re: IGNOREEOF is ineffective when holds a big integer

On Wed, Jun 18, 2025 at 03:59:52 +, shynur . wrote: > Martin: > > In variables.c at line 6243 we have > > eof_encountered_limit = (*temp && all_digits (temp)) ? atoi (temp) : 10; This use of atoi is unique to the IGNOREEOF variable and does not occur in most other places in bash. hobbit:/usr

Re: IGNOREEOF is ineffective when holds a big integer

On Wed, Jun 18, 2025 at 02:31:06 +, shynur . wrote: > ``` > INT_MAX=`echo \`printf '%u' -1\`/2 | bc` > IGNOREEOF=INT_MAX > # Then I typed C-d, bash exited... > ``` You probably meant to type $INT_MAX there, not INT_MAX. You assigned a string to the IGNOREEOF variable, not a number. According

Re: ${name} vs ${name-} with ${...//...}

On Mon, Jun 16, 2025 at 18:51:23 +0200, Lionel Cons wrote: > Why do these two lines differ in output? ${name} and ${name-} should > produce identical output if "name" exists as variable, or not? > > $ (name='bar" x' ; name="${name-//\"/}" ; printf "%q\n" "$name") > 'bar" x' > $ (name='bar" x' ;

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

On Sat, Jun 14, 2025 at 03:17:09 -0600, Stan Marsh wrote: > (Followup to my previous post) > > To answer my own question, I guess it is pretty obvious that the answer to > "How to > fix?" is "Install texinfo and re-run the make install", but it raises two > important > questions: > 1) Why is

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 08:14:51 -0600, Stan Marsh wrote: > >According to : > > I can't access that URL - get "Bad Gateway" (in at least two different > browsers) Sometimes if there are too many requests all at once, it can get a bit cranky. Wait a

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 07:57:54 -0600, Stan Marsh wrote: > Also, note that if you are running with "set -e" (or "trap ... ERR"), then > having > "let" (or "(( ))") return a non-zero exit status when it happens to evaluate > to zero, > could cause an unexpected script abort. This is why I linked

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote: > BTW, and only tangentially related, "man bash" says that "let" and "(( ))" > are exactly > the same, but "shellcheck" thinks otherwise. "shellcheck" says you should > use "(( ))" > and never use "let", but I still (mostly) use "let". T

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 12:41:16 +0300, Stamatis Mavrogeorgis wrote: > The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic > erroneously return exit code 1 when a variable is either incremented by > "++" or decremented by "--" from 0 or incremented by "+=1" or decremented > by "-=

Re: static build fails with 5.3 rc2

On Wed, Jun 11, 2025 at 11:41:30 +0200, Matthias Klose wrote: > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_termcap.o):(.bss+0 > x8): multiple definition of `UP'; > ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:56: fir > st defined her

Re: `help cut` doesn't document what -a does

On Fri, Jun 06, 2025 at 14:19:33 +1000, Duncan Roe wrote: > If one is building bash from source, then (most of) the loadable builtins > are built and installed (at least since bash 4.4). That hasn't been my experience. "./configure" followed by "make" puts a "bash" executable file in the top-leve

Re: `help cut` doesn't document what -a does

On Fri, Jun 06, 2025 at 12:55:34 +1000, Duncan Roe wrote: > On Thu, Jun 05, 2025 at 06:55:55AM -0400, Greg Wooledge wrote: > > On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote: > > > i installed bash dev , but there is no `help cut` > > > > It's a &qu

Re: `help cut` doesn't document what -a does

On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote: > i installed bash dev , but there is no `help cut` It's a "loadable builtin". You have to build those, install them, and then load the "cut" builtin explicitly.

Re: combination of source and && does not result in current alias to be expanded

On Sat, May 24, 2025 at 15:00:21 -0500, Bob Mroczka wrote: >    #!/bin/bash >    set -o pipefail >    shopt -s expand_aliases >    alias ub='echo hi' >    echo "alias ub='echo bye'" >~/.alias >    cat ~/.alias >    source ~/.alias && ub >    ub I believe you've run into the issue described in this

Re: grouping via {} fails after "test $PIPESTATUS"

On Sat, May 24, 2025 at 10:43:39 -0400, Steve Newcomb wrote: > true && { >     echo here 1 >     test "$PIPESTATUS" "!=" "0" >     #echo here 2 > } || { >     echo here 3 > } Don't do that. && || is NOT a substitute for if. They do not have the sa

Re: Difference in POSIX regular expression for bash's '=~' operator and POSIXLY_CORRECT grep -E

On Tue, May 20, 2025 at 19:08:10 +, FunnyMan Computer wrote: > I failed multiple times on getting similar results to what I was > expecting from using grep just using the [a-z] and [a-z]+ classes - > expecting multiple results from $BASH_REMATCH but it's only picking >

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

On Sun, Apr 20, 2025 at 17:31:56 -0400, Chet Ramey wrote: > On 4/20/25 3:08 AM, Stephane Chazelas wrote: > > > $ printf '%b\0' winter 'spring\0315' summer automn | > > bash -c 'while IFS= read -rd "" season; do printf "<%q>\n" "$season"; > > done' > > > > <$'spring\315'> > > > > > > skippi

Re: Bash shell uses wrong language

On Mon, Apr 14, 2025 at 10:44:06 -0400, Chet Ramey wrote: > According to > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_02 > > only gettext(3) looks at LANGUAGE, and that behavior can't be modified by > any calls to setlocale(3). gettext(3) is responsible for ov

Re: Bash shell uses wrong language

On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote: > > bash --version > > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu) > > Copyright (C) 2022 Free Software Foundation, Inc. > > Lizenz GPLv3+: GNU GPL Version 3 oder jünger > > > > > > Dies

Re: /dev/tcp feature request...

On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > On Tuesday, April 8, 2025, A. James Lewis wrote: > > I have however found it extremely frustrating to open TCP connections > > via /dev/tcp, because there appears to be no way to control the > > timeout! > > Same. It'd be nice if bash gave up

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 13:09:45 +0100, Léa Gris wrote: > $ LC_ALL=C locale > LANG=fr_FR.UTF-8 > LANGUAGE=fr_FR:fr_CA:en > LC_CTYPE="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_PAPER="C" > LC_NAME="C" > LC_ADDRESS="C" > LC_TELEPHONE="C" > LC_MEASUREME

Re: ;exit in bash history causes bash to exit

On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > when bash reads exit cmd it will exit > so bash reads rc and exits .. > also .. u may have a ';exit' alias .. The claim is that the ;exit appears in .bash_history (not .bashrc) and that this somehow causes a new instance of bash to exit.

Re: $*, and $IFS, again

On Sun, Mar 16, 2025 at 04:39:33 +0700, Robert Elz wrote: > ps: to anyone out there still reading this, when writing sh code, don't > lapse into writing C instead, in sh, when using quotes, use '' (or \) > whenever the quoted text is to be treated literally, and "" only when > you are expecting exp

Re: Heredoc with a multiline delimiter

On Sat, Mar 15, 2025 at 16:14:00 +, Nikola Novak via Bug reports for the GNU Bourne Again SHell wrote: > Hello! > > How do you end the heredoc with a multiline delimiter such as the following: > > cat << "a > b" You don't.

Re: $*, and $IFS, again

On Fri, Mar 14, 2025 at 01:34:48 +0100, Steffen Nurpmeso wrote: > a() { > echo $#,1="$1"/$1,2="$2"/$2,3="$3"/$3,4="$4" > echo $#,'*'="$*"/$*, > } > set -- '' 'a' '' > #IFS=\ ; echo "$*"$* $*; a "$*"$* $*;unset IFS > #IFS= ; echo "$*"$* $*; a "$*"$* $*;unset IFS > IFS=:; echo "$*

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: bash --pretty-print and pattern

On Thu, Feb 20, 2025 at 21:25:45 +0900, Koichi Murase wrote: > $ bash --pretty-print -O extglob test.sh Yeah, I misread the question a little bit. Sorry about that. By the way, is this considered a bug: hobbit:~$ bash -O extglob --pretty-print x bash: --: invalid option Usage: bash [GNU long

Re: bash --pretty-print and pattern

On Thu, Feb 20, 2025 at 13:50:29 +0200, Timotei Campian wrote: > *OS*=debian12 > *BASH_VERSION*="5.2.15(1)-release" > > the script test.sh has the following content: > > echo !(file.f*) > > > Now calling bash pretty-print result in this error: > > *bash --pretty-print test.sh* > > file1: lin

Re: history writes to process substitution but errors reading it

On Fri, Feb 14, 2025 at 05:19:48 -0600, MacBeth wrote: > On Fri, Feb 14, 2025 at 4:31 AM MacBeth wrote: > > # fails: > > $ history -r <(echo 'echo bad') > > Unless the reason is due to the file seek issue as described here...? > https://unix.stackexchange.com/a/164109 hobbit:~$ echo ': testing f

Re: "printf %d ''" should diagnose the empty string

On Thu, Feb 13, 2025 at 08:17:45 +0300, Oğuz wrote: > Changes made to built-in printf have to be adopted by GNU printf, otherwise > the user will have two flavors of printf on the same system by the same > name. On Debian 12, /bin/echo (which is from GNU coreutils) and bash's builtin echo do not s

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 23:13:33 +0100, Phi Debian wrote: > 029 is not a number Many people would disagree. Of course, it depends on the needs of the script that's being written -- that's why the wiki page offers so many different answers. In my experience, it's pretty rare for a script to *want

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 17:32:24 +0100, Phi Debian wrote: > On Mon, Feb 10, 2025 at 3:43 PM Greg Wooledge wrote: > > > > > Can you please explain *how* this is working in older bash versions? > > > > I forgot to mention 'best on modern bash' :-), >

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 15:20:55 +0100, Phi Debian wrote: > If 'best *general*' refer to the shortest line noise does > > $((${i/?([-+])/&10#})) > > Qualify for better than best ? :-) if so you may add in your web bible > don't forget to mention the inventor :-) Can you please explain *how* this

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 09:50:01 +0100, Phi Debian wrote: > On Sat, Feb 8, 2025 at 8:51 AM Robert Elz wrote: > > There are a gazillion different ways of getting rid of the octal > > conversion "problem", one I prefer in cases where I know the value > > is 2 digits, always, but might be 0n for 0<=n

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

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

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: return [n] documentation.

On Thu, Feb 06, 2025 at 14:54:29 -0500, Chet Ramey wrote: > On 2/6/25 12:59 PM, Greg Wooledge wrote: > > > If extdebug really does imply functrace, then that's missing from the > > documentation. The rest appears to be working as intended. > > Look at item 5

Re: return [n] documentation.

On Thu, Feb 06, 2025 at 18:41:14 +0100, Phi wrote: > I find the docco for return [n] not easy to interpret. Here is what can be > read. > >return [n] > Stop executing a shell function or sourced file and > return the value specified by n to its caller. >

Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)

On Mon, Feb 03, 2025 at 23:37:12 -0500, Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > READ THIS > > To be more clear here the GNU BASH shell that I tested with is merely > a test case and the configuration was very harsh : > > $ ./configure --prefix=/home/dclarke/local --enable-

Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)

On Mon, Feb 03, 2025 at 23:08:53 -0500, Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > READ THE BUG REPORT > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284513 The bug report says: The default FreeBSD bourne shell /bin/sh seems to ignore the terminal config flag ech

Re: [PATCH] Preserve echoctl setting in sh‑mode (lib/sh/shtty.c)

On Mon, Feb 03, 2025 at 17:43:38 -0500, Zeffie via Bug reports for the GNU Bourne Again SHell wrote: > 1. `echo $BASH_VERSION` is Irrelevant > You seem to have completely misunderstood the context of the bug report. The > command: > > ```sh > echo $BASH_VERSION > ``` > is entirely irrelevant in t

Re: Docs typo, :- vs -

On Fri, Jan 31, 2025 at 01:42:38 +0100, Alfred Agrell wrote: > Hello > > https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.info#n1842 > > '${PARAMETER:-WORD}' > If PARAMETER is unset or null, the expansion of WORD is > substituted. Otherwise, the value of PARAMETER is substitute

Re: Set command lists the shell variables and values, then lists other text (Script?)

On Sun, Jan 26, 2025 at 17:40:35 -0500, Pete Edwards wrote: > The set command executed should list the shell variables and values, which > it does, but it is followed by other text, which looks like script text > that has no purpose in the output expectred. The "set" command shows variables *and*

Re: printf width format specifier doesn't work when assigned

On Sun, Jan 26, 2025 at 11:16:27 +0100, Phi Debian wrote: > $ printf -v foo "%(*)T" {1..4} ; echo "'$foo'" > '' I've added this one to .

Re: printf width format specifier doesn't work when assigned

On Sat, Jan 25, 2025 at 15:56:39 +0100, Andreas Kähäri wrote: > Je Sat, Jan 25, 2025 at 07:16:14AM +, Ross skribis: > > However: > > foo=$(printf "%*s\n" 80 " " | tr " " "*") > > echo $foo > > acts very differently; it seems to perform ls or something similar. > This is no bug in bash

Re: Tilde is expanded in $PATH, inconsistent behavior

On Thu, Jan 23, 2025 at 18:15:38 -0800, Keith Thompson wrote: > $[...] appears to behave like $((...)). Is it equivalent? It was the proposed syntax for arithmetic in a POSIX draft a couple decades ago. Bash implemented it, and it started to catch on. But then POSIX went with $(( )) instead. $

Re: Suggestion of wording for portion of man page

On Sat, Jan 18, 2025 at 16:42:59 -0500, Lawrence Velázquez wrote: > It is true that the man page and texinfo manual do not define > "character". (It does not mean "abstraction"; I'm not sure how you > arrived at that conclusion). That was my word. If you have a better one, I'd love to hear it. I

Re: Suggestion of wording for portion of man page

On Sat, Jan 18, 2025 at 12:07:55 -0800, Wiley Young wrote: > No, it isn't that the sentence could be read that way, it's that the > sentence can't not be read that way. It's ambiguous. Do you know what "ambiguous" means? It literally means that something can be interpreted in multiple ways. So,

Re: Suggestion of wording for portion of man page

On Fri, Jan 17, 2025 at 23:32:18 -0500, Lawrence Velázquez wrote: > Here's an attempt at clarification that restructures the section > and describes the behavior of ${foo^x} more explicitly. It also > avoids the aforementioned confusion between the ^/, "operators" > and the ^/, "expansions". > >

Re: READ builtin returns wrong value

On Fri, Jan 17, 2025 at 21:11:12 +0100, dv wrote: > Description: > # If the input string of a READ matches a variable in the script, REPLY is > # set to the value that variable, not to the string. > declare -i int There's your problem: you're using the -i attribute on a variable without understan

Re: Suggestion of wording for portion of man page

On Thu, Jan 16, 2025 at 21:16:47 -0800, Wiley Young wrote: > Well, however an amendment might occur, "Each character in the expanded > value of parameter is tested against pattern" to my ear reads as referring > to alphabetic characters, as per sentence one, however they may appear in > binary. Ch

Re: 'read' sometimes truncates trailing field delimiter

On Mon, Jan 13, 2025 at 04:11:46 -0500, Lawrence Velázquez wrote: > What exactly is all of this supposed to demonstrate? mapfile has > the same terminator-not-separator behavior everyone is kvetching > about: > > $ printf 'a:b:c:' | { mapfile -td:; declare -p MAPFILE; } > declare -a M

Re: 'read' sometimes truncates trailing field delimiter

On Mon, Jan 13, 2025 at 08:42:39 +0700, Robert Elz wrote: > It is unexpected, because users believe (from other experience) > that the delimiters separate fields, but in sh they don't, they > terminate fields. At the risk of going a bit off topic, may I ask *why* the shell does that? Were there a

Re: 'read' sometimes truncates trailing field delimiter

On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote: > > In this case, we get the "expected" result: > > You just restated the original example while ignoring the part of my > message about looking for additional input after you find a delimiter. Right. You explained why it works the way it

Re: 'read' sometimes truncates trailing field delimiter

On Sun, Jan 12, 2025 at 16:10:03 -0500, Chet Ramey wrote: > This is a combination of two rules: characters in IFS are field > terminators, not separators, and when `read' is supplied fewer > variables than fields, > > "Any remaining input in the original field being processed shall be > returned t

Re: 'read' sometimes truncates trailing field delimiter

On Sat, Jan 11, 2025 at 08:54:43 -0600, MacBeth wrote: > It seems that `read` truncates a trailing delimiter if there is one less > variable argument than input fields and the last field is empty (trailing > delimiter). https://mywiki.wooledge.org/BashPitfalls#pf47 "It's a feature."

Re: SHELLOPTS environment variable causes shell options to cascade

On Sun, Jan 05, 2025 at 19:10:41 +0900, Koichi Murase wrote: > I confirmed this behavior, which I think is unreasonable. > > $ (export SHELLOPTS; set -u; bash +u -c 'echo $unset') > bash: line 1: unset: unbound variable > > I think an option explicitly specified in the command-line arguments

Re: Consolidate recommended options?

On Tue, Dec 31, 2024 at 12:15:27 -0500, Chet Ramey wrote: > On 12/29/24 4:34 PM, Lawrence Velázquez wrote: > > I'm aware of the pitfalls described therein, and more. I don't > > think anyone thinks multiple evaluation in indexes is good per se, > > but many find the side effects of the attempted c

Re: Logical expression works does not work as expected

On Sat, Dec 28, 2024 at 15:23:41 -0500, Lawrence Velázquez wrote: > On Fri, Dec 27, 2024, at 6:47 PM, Greg Wooledge wrote: > > You might have been raised on some other language where the && and || > > operators have different precedence. In the shell language, they have

Re: Logical expression works does not work as expected

On Sat, Dec 28, 2024 at 00:52:59 +0300, Павел Fortovey wrote: >I apologize. I found out that this behavior is not a bug. > >I didn't think that bash is such a strange scripting language with its >own interpretation of the concept of logic. >Repeat-By: > >bash -c "true

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 13:45:19 +1000, Martin D Kealey wrote: > Failing that, by far the "simplest" approach to "literal" text is not to > have it inside the script, but in a separate file that the script can read. Yes, this. I omitted this case in my initial reply, thought of it later, but didn

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 07:29:14 +0700, Robert Elz wrote: > Date:Sat, 21 Dec 2024 13:49:48 -0500 > From: Greg Wooledge > Message-ID: <20241221184948.gm29...@wooledge.org> > > | Choice #2: use $'...' quoting, > | Choice 2 is a ba

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sat, Dec 21, 2024 at 09:56:15 -0800, Eric Pruitt wrote: > On Sun, Dec 22, 2024 at 12:49:07AM +0700, Budi wrote: > > How is Bash' code to store string of any characters should be containing > > pair of "" and '' at the same time explicitly, being exact verbatim so, > > ie. cannot be modified, esc

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 00:49:07 +0700, Budi wrote: > How is Bash' code to store string of any characters should be containing > pair of "" and '' at the same time explicitly, being exact verbatim I'm interpreting this as: * You would like to store some data in a string variable. * The data is

Re: An inconsistency of the outputs of help builtin

On Fri, Dec 20, 2024 at 19:30:49 -0500, Lawrence Velázquez wrote: > On Fri, Dec 20, 2024, at 8:09 AM, Greg Wooledge wrote: > > help -d cdoes not exactly match anything, so it's treated like c\* > > Is this documented somewhere? I'm not seeing anything about it in

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Fri, Dec 20, 2024 at 11:04:35 -0500, Zachary Santer wrote: > On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey wrote: > > So you're saying that bash looking at a specific variable and using its > > value should fail if that variable is unset? How far do you want to > > take that? PS2? PS4? GLOBIGNORE

Re: An inconsistency of the outputs of help builtin

On Fri, Dec 20, 2024 at 04:50:17 -0800, Wiley Young wrote: > For some reason, while `help -d 'c'` prints the same thing as `help -c > 'c*'` (note the asterisk), the same is not true when the character is > left-bracket: `help -c '[*'. Why did you expect them to be the same? Assuming you meant -d

Re: history -s from inside function replaces last command rather than adding to it

On Tue, Dec 17, 2024 at 17:48:15 +, Bug Maybefound wrote: > I assumed it must be from a more recent bash than I have since mine doesn’t > have it: > > $ help history > > -pperform history expansion on each ARG and display the result > without storing it in the hi

Re: history -s from inside function replaces last command rather than adding to it

On Mon, Dec 16, 2024 at 21:46:21 -0500, Chet Ramey wrote: > On 12/16/24 9:36 PM, Dale R. Worley wrote: > > Chet Ramey writes: > > > Yes: > > > > > > -s Store the args in the history list as a single entry. > > > The last command in the history list is removed

Re: Very Unexpected response from command 'set'

On Sun, Dec 15, 2024 at 07:53:44 +0800, HP Prototyping wrote: > Please find attached the edited file ('user_name' , 'HOSTNAME' , (UU)IDs) > for privacy concerns. > I do have a copy of the original file in case some details like a UUID and > another long ID number would be absolutely necessary for y

Re: PIPESTATUS differs from $? for compound command

On Tue, Dec 10, 2024 at 09:28:31 +0100, Ulrich Müller wrote: > Then what about these? > > $ true; case a in esac > $ echo "ret = $?, status = ${PIPESTATUS[*]}" > ret = 0, status = 0 > > $ false; case a in esac > $ echo "ret = $?, status = ${PIPESTATUS[*]}" > ret = 0, status = 1 > > "case a in es

Re: One IFS non-whitespace is stripped at the end of a word during word splitting

On Sun, Dec 08, 2024 at 10:27:33 +0200, Yuri Kanivetsky wrote: > $ bash -c 'IFS=x; a=ax; f() { for arg; do echo "($arg)"; done; }; f $a' > (a) Another responder has already given an explanation, but just for redundancy: The good news is that there's

Re: history -f filename

On Sun, Dec 01, 2024 at 10:36:53 +0800, Dan Jacobson wrote: > $ history |wc - $HISTFILE|sed \$d >7622 75741 532254 - > 14973 29625 320996 /home/jidanni/.bash_history_jidanni > Works as expected. So, you have 7622 lines of history in memory, and 14973 lines in that file. > $ (a=~/.bash

Re: Regression: EXIT traps always run in global context

On Thu, Nov 28, 2024 at 08:23:48 +0400, Ivan Shapovalov wrote: > Bash Version: 5.2 > Patch Level: 37 > Release Status: release > > Description: > Regression: When an EXIT trap runs, it runs in global context, i.e. > does not see the locals defined in the function that was executing >

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: [PATCH 03/25] doc/bash.1: Clarify program/man page reference.

On Thu, Nov 21, 2024 at 22:19:13 -0600, G. Branden Robinson wrote: > diff --git a/doc/bash.1 b/doc/bash.1 > index 23a8dbd6..6c864eab 100644 > --- a/doc/bash.1 > +++ b/doc/bash.1 > @@ -6962,7 +6962,8 @@ .SS "Readline Variables" > its value may change if the locale changes. > .TP > .B page\-comple

Re: Built-in `test -a` returns incorrectly

On Mon, Nov 18, 2024 at 11:31:25 +, Klüver, Tibor wrote: > Built-in `[ -a ... ]` returns true when false, negation with `!` is > also very strange. > `[[` is not affected, neither is `/bin/[`. > > Repeat-By: > * touch file > * [ -a file ] && echo exists

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: redirection / process substitution fails to read a file descriptor

On Sun, Nov 17, 2024 at 12:16:29 -0600, Mike Peters wrote: > On 2024-11-16 20:35, Greg Wooledge wrote: > > On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote: > > > > exec 3 > > > cat <&3 > > > foobar > > > &

Re: redirection / process substitution fails to read a file descriptor

On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote: > Description: > Process substitution does not generate properly when pulling from > another file descriptor, although it works when pulling from a file directly. > In the below sample shell session, it is expected that `<( be fun

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 15:56:57 -0800, Yuri wrote: > On 11/13/24 15:44, Greg Wooledge wrote: > > If the "user script" runs quickly enough, then: source userscript > > >logfile 2>&1 cat logfile > > > This would fail to save the user script's outpu

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 15:18:58 -0800, Yuri wrote: > I need to (1) source the user script, (2) save this script's output to a > dedicated file, (3) keep the same output in stdout, and (4) keep environment > variables that the user script sets for later commands. If the "user script" runs quickly

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

On Wed, Nov 13, 2024 at 13:48:18 -0800, Yuri wrote: > # source is piped into tee > source child.sh | tee /dev/null > echo "XVAR=$XVAR" > echo "YVAR=$YVAR" > > # source is un-piped > source child.sh > echo "XVAR=$XVAR" > echo "YVAR=$YVAR" > The first 'source' command didn't set variables set or ex

Re: [EXTERNAL] - Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

On Fri, Nov 08, 2024 at 15:33:29 +, David Linden wrote: > FYI, since I'm reporting behavior of 4.2 and this appears fixed in 4.4. > > In 4.2, it seems that providing the =() as part of the declaration throws > away the -g-ness of the declaration-within-a-function. I need to touch it > after

Re: Bash 5.2: broken built-in printf for float numbers

On Thu, Nov 07, 2024 at 10:16:46 +0100, Thomas Dreibholz wrote: > Hi, > > Bash 5.2 has a broken built-in printf for float numbers. > > Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale > LC_ALL=C.UTF-8) > > Testing the Bash shell in different versions of recent Debian and

Re: This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo ${#foo[@]}

On Thu, Nov 07, 2024 at 02:38:05 +, David Linden wrote: > Description: > This errors in 4.4, did not in 4.2: set -u; declare -A foo; echo > ${#foo[@]} > How am I supposed to determine that a declared associative array is > empty? The easiest way would be to ensure that the array

Re: bash -xv issue with stderr

On Sun, Nov 03, 2024 at 11:28:24 +0100, Christoph Zimmermann wrote: > Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which unfortunately does require a CB change). > > If this is intended behaviour, it should be clearly documented on the > corresponding man pa

IFS whitespace definition

This issue came up on the Libera #bash IRC channel today: Between bash 4.4 and 5.0, the definition of "IFS whitespace" has apparently been expanded: hobbit:~$ bash-4.4 hobbit:~$ ( s=$'a\r\r\rb'; IFS=$'\r' read -ra a <<< "$s"; declare -p a ) declare -a a=([0]="a" [1]="" [2]="" [3]="b") hobbit:~$ e

Re: Call dynamic builtins with 'builtin' command

On Sat, Oct 12, 2024 at 16:55:31 -0400, Chet Ramey wrote: > On 10/9/24 7:15 AM, Vadim Nevorotin wrote: > > 2. Can you explain how to load and use e.g. stat builtin without > > overwriting the current behavior of stat in the whole existing script? > > Is this anything more complicated than doing >

Re: Fwd: New feature

On Sat, Oct 12, 2024 at 09:50:03 -0400, Saint Michael wrote: > The command printf needs a new flag, -e, that would mimic that way the > same flag works with echo. > After using printf, right now I need to lunch a second command if I > need to expand the \n into real new lines. > > PROCEDURE_INFO=

Re: aliases sometimes not expanded even with expand_aliases set

On Sun, Oct 13, 2024 at 00:01:10 +1030, i...@beware.dropbear.id.au wrote: > In the following script, the first alias fails with "comand not found" > but the second works. > > #!/bin/bash > > shopt -s expand_aliases > > if :; then > alias foo='ec

Re: Call dynamic builtins with 'builtin' command

On Wed, Oct 09, 2024 at 15:15:52 +0400, Vadim Nevorotin wrote: > According to 'help enable' this should work, but it also do not: > > $ enable stat > $ enable -n stat > $ builtin stat > bash: builtin: stat: not a shell builtin > > 'enable -n' should just disable stat, according to 'help enable',

Re: Fwd: read command sometimes misses newline on timeout

> -- Forwarded message -- > From: *Thomas Oettli* >1. the script calls "read" on pipe >2. "read" hits timeout just after it has read "\n" from the pipe >3. "read" returns the full line, but exits with rc > 128 >4. the script assumes a partial line, appends received

  1   2   3   4   5   6   7   8   9   10   >