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

ntor :-) Can you please explain *how* this is working in older bash versions? According to the CHANGES file, the processing of `&' by patsub_replacement is new in bash 5.2. And yet: hobbit:~$ bash-2.05b bash-2.05b: /home/greg/.bashrc: line 95: syntax error in conditional expression: unexp

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

Re: Suggested BASH Improvement

On Wed, Sep 18, 2024 at 10:51:51 -0400, Chet Ramey wrote: > On 9/17/24 7:50 PM, BRUCE FOWLER via Bug reports for the GNU Bourne Again > SHell wrote: > > An interesting problem I ran into recently: > > I have a shell script that I run about once a month that > > "screen-scrapes" from the output of a

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

On Wed, Sep 18, 2024 at 08:05:10 +0300, Oğuz wrote: > On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso wrote: > > > > It boils down to this: > > f(){ echo $#;}; set "" "" ""; IFS=x; f $* > > bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh > prints 3 but mksh and oksh print

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 17:00:16 +0200, alex xmb sw ratchev wrote: > plz what does 'local -' do , its newer to me > i forgot all about it already local [option] [name[=value] ... | - ] For each argument, a local variable named name is created, and assigned valu

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 16:07:58 +0200, alex xmb sw ratchev wrote: > savedifs=${IFS@A} savedifs=${savedifs:- unset -v IFS } > str=1,2,3 IFS=, arr=( $str ) joined=${arr[*]} > eval "$savedifs" Using unquoted $str in an array expansion to do the splitting has a couple drawbacks: 1) Globbing (filenam

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 02:56:05 -0400, Lawrence Velázquez wrote: > This question is more appropriate for help-bash than bug-bash. > > On Tue, Sep 17, 2024, at 2:21 AM, William Park wrote: > > For splitting, I'm aware of > > old="a,b,c" > > IFS=, read -a arr <<< "$old"

Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

On Sat, Sep 14, 2024 at 19:46:21 +0800, ~ via Bug reports for the GNU Bourne Again SHell wrote: > Dear bug-bash team: >   I hope this email finds you well. During my recent security > assessment of bash, I identified a potential security vulnerability that I > believe may impact the security of

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

On Sat, Aug 24, 2024 at 02:15:48 +0200, Steffen Nurpmeso wrote: > a() { > echo $#,1=$1,2=$2,"$*",$*, > } You didn't read a word I said, did you *Sigh.*

Re: Question on $@ vs $@$@

On Fri, Aug 23, 2024 at 01:28:49 +0200, Steffen Nurpmeso wrote: > a() { echo $#,1=$1,2=$2,"$*",$*,; } > set -- a b c > echo 2 > IFS=:; echo "$*"$*; a $* "$*"; Your printing function "a" is highly questionable. It's got unquoted word expansions that'll do who knows what, and it's also usin

Re: Bash History Behavior Suggestion

On Mon, Aug 19, 2024 at 15:52:22 -0400, supp...@eggplantsd.com wrote: > I would suggest: > 2. Restrict up-arrow completion to the history of present session. This is going to be an *extremely* unpopular suggestion. Though, I must wonder: do you literally mean *only* the up-arrow (or Ctrl-P or ESC

Re: $@ in function gives error

On Sat, Aug 17, 2024 at 12:41:45 +0200, Freek de Kruijf wrote: > Apparently I have a problem with the concept of $@, I see it as list of zero > or more non-whitespaced elements, and quotes around it makes it into a single > element. Like a parameter p with a content of zero or more non-whitespace

Re: $@ in function gives error

On Fri, Aug 16, 2024 at 18:59:15 +0200, freek--- via Bug reports for the GNU Bourne Again SHell wrote: > #!/bin/bash > init() { > [ -n "$@" ] && echo $@ > } > init $@ You have multiple errors in this script. The first error is that you used $@ without quotes, twice. If you want to preserve the

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 17:58:15 +0300, Oğuz wrote: > On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > > However, as ksh93 makes "" from this > > expansion, and so probably ksh88 might have done as well > > No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0. HP-UX 10.20 a

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 11:04:08 +0200, Marc Chantreux wrote: > > We know what "$@" is supposed to do. And something like "x${@}y" is > > well-defined also -- you simply prefix "x" to the first word, and append > > "y" to the final word. > > > But I don't know how "$@$@" is supposed to be interpr

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 02:45:25 +0200, Steffen Nurpmeso wrote: > I include bug-bash even though i think bash is correct, but there > lots of people of expertise are listening, so, thus. > Sorry for cross-posting, nonetheless. > Given this snippet (twox() without argument it is) > > one() { echo

Re: printf inconsistent results for %.0f

On Mon, Aug 12, 2024 at 16:30:26 +0200, Laur Aliste wrote: > Configuration Information: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -fcf-pr

Re: 'wait -n' with and without id arguments

On Fri, Aug 09, 2024 at 15:20:52 -0400, Zachary Santer wrote: > On Fri, Aug 9, 2024 at 2:52 PM Greg Wooledge wrote: > > > > The problem is that our entire understanding of what "wait -n" DOES has > > been annihilated. We thought it would "trigger" exactl

Re: 'wait -n' with and without id arguments

On Fri, Aug 09, 2024 at 13:59:58 -0400, Zachary Santer wrote: > I don't necessarily understand why someone would call 'wait -n' from > the interactive shell, so I don't really know what the desired > behavior would be when they do so. Would be nice if other people want > to chime in on that point.

Re: whats wrong , exit code 11 on android termux

On Tue, Aug 06, 2024 at 20:59:08 +0200, alex xmb sw ratchev wrote: > maybe its this i completly dunno > > i guess i must start use devel branch ? > > On Tue, Aug 6, 2024, 20:45 Grisha Levit wrote: > > > On Tue, Aug 6, 2024, 14:19 alex xmb sw ratchev wrote: > > > >> ~ $ alias tm='timemark+=( $E

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: Backticked, nested command will steal piped stdin

On Tue, Jul 30, 2024 at 14:06:21 -0400, Dale R. Worley wrote: > In your case, you probably want > > > $ seq 3 | head -n $(

Re: if source command.sh & set -e issue

On Wed, Jul 24, 2024 at 20:53:33 +0300, Mor Shalev via Bug reports for the GNU Bourne Again SHell wrote: > *if source command.sh ; then echo passfi* > Or, similarly: > > *source command.sh && echo pass* Remember how -e is defined: -e Exit immediately if a pipeline (which m

Re: if source command.sh & set -e issue

On Wed, Jul 24, 2024 at 16:23:35 +0300, Mor Shalev via Bug reports for the GNU Bourne Again SHell wrote: > script.sh contain: > if source command.sh ; then > echo pass > else > echo fail > fi > command.sh contain 'set -e' at start. so command.sh should exit once detect > fail. > > once callin

  1   2   3   4   5   6   7   8   9   10   >