square bracket vs. curly brace character ranges

-dependent [a-c] suggests to me that the software should be changed to just do what people expect, especially since nothing is really lost by doing so. Oh well. Dead horses and all that -- but can we at least make the dead horses consistent? :) ~Felix.

show-all-if-ambiguous inserts spurious backslashes

the user wanted. ~Felix.

completion of '../' with symlink component in CWD path

. ~Felix.

Difference between EPOCHREALTIME and EPOCHSECONDS

Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux medium 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level:

Re: Subject: Pressing Ctrl-C during any subshell evaluation terminates the shell

Issue 627 in direnv's github project show: To reproduce this simply: PROMPT_COMMAND="trap -- '' SIGINT; sleep 0.1; trap SIGINT;" read foo ^C -- will exit current shell -- On Mon, Oct 12, 2020 at 09:52:21PM -0700, Daniel Farina wrote: > On Sun, Oct 11, 2020 at 12:59 PM

Re: Bash-5.1-beta available

Hi, On Mon, Sep 21, 2020 at 09:13:13PM -0400, Dale R. Worley wrote: > Andreas Schwab writes: > I assume that if you really want the old effect, you can still do > > exec {dup}<&1 You mean: exec {dup}<&0 > > ... <( ... <$dup ) ... and: ... <( ... <&$dup ) ... > > exec

read with very small timeout sometime hand on stdin

Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux medium 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch

Re: Undocumented feature: Unnamed fifo '<(:)'

Thanks Pierre, On Sun, Jun 28, 2020 at 10:48:42PM +0200, Pierre Gaston wrote: > Maybe "coproc" is already the feature you need (limited to only 1 though)? Correct: I missed this! This work fine: coproc stdbuf -o0 date -f - +%s 2>&1 DATEIN=${COPROC[1]} DATEOUT=$COPROC echo >&$DATEIN

Undocumented feature: Unnamed fifo '<(:)'

Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux medium 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2

Re: Undocumented feature: Unnamed fifo '<(:)'

I totally agree, but this work from at least bash-3.2 upto last version! But if a bug, a feature request: exec 8< 9> <>(date -f - +%s) ( ..or, but I don't imagine how this could be implemanted: exec 8<> <>(date -f - +%s) :-p ) ... AND even: Same `-u` option for `read -u $FD` available

Re: Undocumented feature: Unnamed fifo '<(:)'

> } > > _out=$(date_to_epoch "$_string") > On Sun, Jun 28, 2020, 8:50 AM felix wrote: > > ... > > _fifo=$(mktemp -u /tmp/fifo-) > > mkfifo $_fifo > > exec 9> >(exec stdbuf -o0 date -f - +%s >$_fifo 2>&1) > >

Re: Command substitution

Quoting is useless when assigning variable from ouptut of command or another variable: $ foo=1 2 3 4 bash: 2: command not found Ok. But $ foo=$(seq 1 3) $ declare -p foo declare -- foo="1 2 3" $ foo="$(seq 1 3)" $ declare -p foo declare -- foo="1 2

Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE

On Tue, Dec 08, 2020 at 08:07:18PM +0700, pepa65 wrote: > On 08/12/2020 19.55, Greg Wooledge wrote: > > Some terminals, when fed a tab character, will preserve that knowledge > > in memory; then, when you copy text from that part of the terminal > > window using your mouse, the terminal will put a

Re: increment & decrement error when variable is 0

On Mon, Nov 23, 2020 at 05:20:22PM -0500, Greg Wooledge wrote: > On Mon, Nov 23, 2020 at 07:36:29PM +, Jetzer, Bill wrote: >... > Exercises 1 and 2 apply directly... >From man bash: ((expression)) The expression is evaluated according to the rules described be‐

Re: [ping] declare -c still undocumented.

On Fri, Nov 13, 2020 at 12:19:27AM +0100, Léa Gris wrote: > > Happy 10 years 10 months anniversary to the issue: > > > > > address@hidden:~$ declare -c moo=moo; echo $moo > > Moo cap() { local -ca

Re: read with very small timeout sometime hand on stdin

On Wed, Oct 28, 2020 at 09:23:09AM -0400, Chet Ramey wrote: > > I can't reproduce this using the following stripped-down reproducer: > trap 'echo $f ; exit' SIGINT > > for f in {1..1}; do > read -t .01 v > if [ $? -ne 142 ]; then > echo $f: $? > fi > done

Re: read with very small timeout sometime hand on stdin

On Thu, Oct 29, 2020 at 01:57:33PM +0100, felix wrote: > > I can't reproduce this using the following stripped-down reproducer: Sorry to insist, but... This is not easy because not constant. For this, I wrote a little script tested on several host, then searching for instal

Re: bash: please provide an easy way to spawn a new process group from script

On Sun, Nov 01, 2020 at 11:13:37AM +0100, clime wrote: > On Sun, 1 Nov 2020 at 11:01, Oğuz wrote: > > > > You can use the loadable builtin `setpgid' if you have to. Assuming > > BASH_LOADABLES_BUILTIN is set, this should work: > > > > enable -f setpgid{,} > > { setpgid $BASHPID{,}; a |

Re: Bug Using Brackets

Hi, On Wed, Jan 06, 2021 at 11:32:49PM +0800, Harry Lee wrote: > root@server:~# bash -version > GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) > Copyright (C) 2019 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This

Re: V+=1 doesn't work if V is a reference to an integer array element

This seem linked: $ f() { local -a a=('' 'foo'); local -n b=a[1]; echo $b; b+=\ bar; echo $b; declare -p a; } $ f foo foo bar declare -a a=([0]="" [1]="foo bar") Ok, fine! $ bash <(declare -f f | sed '1,2d; $s/.*/echo

Strange behaviour using negative index in arrays

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux medium 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux Machine Type:

Re: New Feature Request

I agree: python seem to be more apropriated language for complex operation. Anyway, bash already offer a lot of features (like `coproc` and `read -t 0`) usefull for IPC. I wrote a little ``multiping`` bash script, as multithread demo, running many parallels ping, reading all outputs and merging

Re: No expansions performed while declaring an associative array using a list of keys and values

On Fri, Dec 11, 2020 at 03:08:04PM +0300, Oğuz wrote: > I was trying the new features of bash 5.1 and came across this inconsistent > behavior: > > $ foo='1 2' > $ declare -A bar=($foo 3) > $ declare -p bar > declare -A bar=(["\$foo"]="3" ) > $ > $ bar+=($foo 3) > $

Re: [PATCH] Prefer non-gender specific pronouns

I totally agree with Léa: Awesome patch, but... Please stop this troll! As children of Gaia for me, there's no matter if Greg is a woman or Léa a men... Are bash male or female!? This forum is technical, not political! I've already seen many human groups splited because of stupid

Re: `&>' doesn't behave as expected in POSIX mode

On Sun, Jun 20, 2021 at 10:18:59AM -0400, Eli Schwartz wrote: > > *Neither* behavior is similar to e.g. dash's behavior, or for that > matter ksh. Both print the uname output after registering it as a > backgrounded job (redirection does not get applied to the command itself). Quick comparission

Re: [patch #10070] toggle invert flag when reading `!'

On Mon, May 24, 2021 at 11:47:32AM -0400, Chet Ramey wrote: > On 5/22/21 2:45 PM, Vincent Menegaux wrote: > > > Details: > > > > Previously, these commands: > > > >[[ ! 1 -eq 1 ]]; echo $? > >[[ ! ! 1 -eq 1 ]]; echo $? > > > > would both result in `1', since parsing `!' set

Re: feature request: ${ regex s expander, and multiple expandrs inside one

On Fri, Feb 05, 2021 at 09:29:49PM +0100, Alex fxmbsw7 Ratchev wrote: > .. > > var=mynewfoo > printf ${var~~n[^f]+} > -> > myfoo > > and also multiple expanders inside one statement would greatly speed up > processment and also fulfill old greatly coding wanting possibilities This could

Re: missing way to extract data out of data

I think, memory footprint doesn't really matter when standard availlable ram is lot away... But *time required to ``fork''* could matter: QuickTest() { local TIMEFORMAT='%R ( %U + %S )'; printf "%-10s: " "${1##*/}"; time for i in {1..1000}; do res=$("$@"); done;

Re: zsh style associative array assignment bug

Quick array assignment from command... > On Tue, Mar 30, 2021 at 12:42:46PM -0400, Eric Cook wrote: > > eval 'tags=('"${*@Q}"\) On Tue, Mar 30, 2021 at 01:16:14PM -0400, Greg Wooledge wrote: > declare -A tags=() > while IFS=\| read -r tag value; do > tags[$tag]=$value > done < <(exiftool ...)

Re: 'exec' produced internal code output instead of normal

On Sat, Mar 13, 2021 at 01:05:32AM +0100, Alex fxmbsw7 Ratchev wrote: > i have no example to write here as this was past long Without sample, i'ts hard to represent your case! > the story was, i was coding a file server daemon, with socat, Wow! > and i figured to use exec why not more exact more

Re: is it normal that set -x unset commands dont display special chars in the content

On Sun, Feb 28, 2021 at 10:32:13PM +, k...@plushkava.net wrote: > Why not indeed. However, I think that I'm able to decipher this. > > $ declare -A map; key=$'foo\34bar'; map[$key]= > $ set -x > $ : "$key" > + : $'foo\034bar' > $ unset "map[$key]" > + unset 'map[foobar]' > > For the unset

uname lead to embed code execution

There it is: $ declare -A map; key='foo$(uname >/dev/tty)bar'; map[$key]= $ echo map["$key"] map[foo$(uname >/dev/tty)bar] $ echo ${map["$key"]} $ unset map["$key"] Linux Or even: $ declare -A map; key='foo$(read -t 3 /dev/tty bar: $foo)bar'; map[$key]= ... $ unset map["$key"] baz # hitted

Re: Undocumented feature: Unnamed fifo '<(:)'

Comming back on this 10month old thread... On Tue, Jun 30, 2020 at 12:30:53PM -0400, Chet Ramey wrote: > On 6/28/20 9:49 AM, felix wrote: > > > Bash Versions: 3.2.57(1)-release, 5.0.3(1)-release, 5.1.0(1)-alpha > > > > In order to reduce forks and make some tasks a lot q

Re: Undocumented feature: Unnamed fifo '<(:)'

On Fri, Apr 09, 2021 at 01:23:09AM +0200, Léa Gris wrote: > > You could have a look: > >https://f-hauri.ch/vrac/mandelbrot_backgndBc.sh.txt > >https://f-hauri.ch/vrac/mandelbrot_backgndBc_4macOs.sh.txt > Have a look at my POSIX/shell version that is even slightly faster: >

Re: [PATCH] Fix blocking read timeouts at a small probability

On Mon, Feb 15, 2021 at 09:41:29AM -0500, Chet Ramey wrote: > Just for testing, not for any real use case. > > > He also provided me with his new test case > > to see the interaction with SIGCHLD. The failure of this test case > > seems to have also involved SIGCHLD in the previous devel Bash.

Re: Squiggly heredoc - new feature request

Hi, > ... ignoring both leading spaces and leading tabs. eg. Something like (there must be nothing but tabulation before closing ``EOF'')? func(){   sed 's/^ \{2\}//' <<- EOF     blabla   EOF } Depending on how and why, there is a lot of *variants*: - leading spaces and/or/not

Re: ?maybe? RFE?... read -h ?

On Sun, Sep 05, 2021 at 11:54:05PM -0400, Lawrence Velázquez wrote: > On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: > > > ... I was wondering, is there a way for bash to know where the > > > symlink points (without using an external program)? > > The distribution ships with a

Re: Why tail coreutil cannot work as its input is from tee

Because your last pipe will pipe BOTH output of `echo` AND `head` with delay due to fork, head output will comme after. try this: echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1 >&2) |tail -1 or echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1 >&2) >(tail -1 >&2) >/dev/null ... On Mon,

Re: ?maybe? RFE?... read -h ?

On Mon, Sep 06, 2021 at 08:11:20AM -0400, Greg Wooledge wrote: > The real one looks like this: > unicorn:~$ help realpath > realpath: realpath [-csv] pathname [pathname...] > Display pathname in canonical form. > > Display the canonicalized version of each PATHNAME argument,

Issue with parameter expansion with array when index > 2^31

Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux medium 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch

Re: Arbitrary command execution from test on a quoted string

Unfortunely, this won't be useable with associative array, like: declare -A AssocVar='([Some string.]=foo)' test -v AssocVar['Some string.'] && echo yes || echo no yes isvar AssocVar['Some string.'] && echo yes || echo no no But Lea's solution seem work: test

Re: gettext feature request

On Tue, Jul 27, 2021 at 10:44:09PM +0200, Jean-Jacques Brucker wrote: > > I like what you wrote 12 years ago ( > https://lists.gnu.org/archive/html/bug-bash/2009-02/msg00258.html ). IMHO, > it could have change some people's mind about bash, and could have saved > developer energy. > > > >

Performances comparission between 5.1 and 5.2.

Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux medium 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 0 Release Status: rc2 Description:

Re: printf %n is not documented

My two cents: Le Tue, Dec 27, 2022 at 03:44:29PM -0500, Chet Ramey a écrit : > > So maybe the better thing to do is to list the set of valid format > specifiers from the standard printf(3) set. > I'm not a C programmer, so I didn't hear about `printf %n` before this thread. Re-reading all `man

Localised variables become exposed to environment when FUNCNEST reached

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux medium 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch

Re: Examples of concurrent coproc usage?

Some other way of thinking: > On 3/14/24 5:58 AM, Carl Edquist wrote: > > ... > > But if you try... > > > > $ coproc WC { wc; } > > $ coproc CAT { cat; } > > $ exec {WC[1]}>&- > > $ read -u ${WC[0]} X > > > > # HANGS To prevent `exec {WC[1]}>&-` to close both FD, just

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

Hi, Comming on this very old thread: On Wed, 4 Dec 2013 14:40:11 -0500, Greg Wooledge wrote: > > The most obvious difference is that $? is shorter. > > $? is also POSIX standard (older than POSIX in fact), so it works in sh > scripts as well. PIPESTATUS is a Bash extension. > > Finally, note

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

Le Mon, Apr 22, 2024 at 07:44:48AM +0100, Kerin Millar a écrit : > On Mon, 22 Apr 2024, at 7:13 AM, felix wrote: > > ... > > if ls /wrong/path | wc | cat - /wrong/path | sed 'w/wrong/path' > > >/dev/null ; then > > echo Don't print this' >

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

Le Mon, Apr 22, 2024 at 10:56:03AM +0300, Oğuz a écrit : > > Me neither, but the current behavior is useful. I agree! Anyway, reading man page, `$?` have to be equivalent to `${PIPESTATUS[-1]}`! which is not always the case. > I've never seen anything like that in a real shell script. I have to

spaces in the shebang interpreter path

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat'

Re: spaces in the shebang interpreter path

Hi Bob, hi Paul, thanks for your detailed explanations. So I agree that this is not a bash bug ;-) Maybe in ten years we will see a Un*x release which will allow the use of spaces in the shebang line *dreaming*. thanks again fs smime.p7s Description: S/MIME Cryptographic Signature

Broken PIPESTATUS with --disable-job-control

test) fails. So by default, a cross-compiled bash will have this bug. -- Felix #!/bin/bash g() { p=$PIPESTATUS if [[ $p -ne 0 ]] then echo FAIL!! fi } f() { false && false true | true g } f

Re: Broken PIPESTATUS with --disable-job-control

Chet Ramey wrote: > On 9/17/16 1:27 PM, Felix Janda wrote: > > Hello, > > > > below this mail you can find a minimal script misbehaving when > > job-control is configured out (tested on linx with different archs, > > libc's, and versions (including current git

Re: Broken PIPESTATUS with --disable-job-control

Chet Ramey wrote: > On 9/18/16 11:20 PM, Felix Janda wrote: > > >>> Notice that the configure script disables job-control when a run-time > >>> test (which could easily be a built-time test) fails. So by default, > >>> a cross-compiled bash will have thi

Re: Broken PIPESTATUS with --disable-job-control

Chet Ramey wrote: > On 9/18/16 11:20 PM, Felix Janda wrote: > > >>> Notice that the configure script disables job-control when a run-time > >>> test (which could easily be a built-time test) fails. So by default, > >>> a cross-compiled bash will have thi

Typo in german translation

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'

Typo in german translation

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'

documentation bug re character range expressions

?!), and that this will eventually lead to character ranges becoming useful again regardless of the current locale. But in the mean time, I would settle for a documentation change, and will continue to export LC_COLLATE=C! :) ~Felix.

Re: documentation bug re character range expressions

guessing that if grep were to start using locale-aware character ranges, a heck of a lot more people would complain than do about bash. This is a seldom-used feature in bash but many, many people rely on grep being predictable and standard. ~Felix. On 2011-06-02 22:32, Jan Schampera wrote: Hi

Re: documentation bug re character range expressions

loss for a fair number of people if it were fixed :) ~Felix.

Re: documentation bug re character range expressions

On 2011-06-03 05:00, Greg Wooledge wrote: On Fri, Jun 03, 2011 at 12:06:32AM -0700, Marcel (Felix) Giannelia wrote: Is it really a programmer mistake, though, to assume that [A-Z] is only capital letters? Yes, it is. You should be using [[:upper:]], or you should be setting LC_COLLATE=C

Re: documentation bug re character range expressions

On Fri, June 3, 2011 10:03, Greg Wooledge wrote: On Fri, Jun 03, 2011 at 09:12:07AM -0700, Marcel (Felix) Giannelia wrote: [...] In HP-UX's en_US.iso88591 locale, the characters are in a COMPLETELY different order. You can't easily figure out what that order is, because it's not documented

Re: documentation bug re character range expressions

a similar situation, and would force 'C' to come after 'c'.) ~Felix.

Re: documentation bug re character range expressions

and ls programs are properly installed [...]) Guess it's time I really learned how to navigate texinfo... (Do I come across as old-fashioned nowadays for still using man?) ~Felix.

Re: A Feature Request for History

years ago, what was it... Ctrl+r (some short string that you know was in that command somewhere) Ah, right, that's it. ~Felix. On 2011-06-13 21:48, Michael Witten wrote: On Mon, Jun 13, 2011 at 17:10, Bradley M. Kuhnbk...@ebb.org wrote: I have all my bash history going back to 2003-10-15

Re: incremental history i/o? (was Re: A Feature Request for History)

,ro,uid=1000 -t vfat /some/file /mnt/temp but ignore cd ~ 'cause you really don't need Ctrl+R to remember the latter). ~Felix. On 16/06/11 12:55, Bradley M. Kuhn wrote: I agree with Marcel's points about keeping a big bash history, although I wasn't sure if discussing why users keep a big bash