Re: Support ksh93 x=${cmd;}

On 4/9/25 9:31 AM, Dan Shelton wrote: On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: On 4/9/25 2:09 AM, Cedric Blancher wrote: Good morning! Could bash please support x=${cmd;} alongside x=$(cmd)? I implemented it back in 2023 and it will be in bash-5.3. There was quite a long discussion

Re: Support ksh93 x=${cmd;}

Besides, HP-UX sh is ksh88 :-) no risk anyone port anything from there.

Re: Support ksh93 x=${cmd;}

On 4/9/25 9:46 AM, Dan Shelton wrote: What is not great is the cmd | x=${|cmd;} extension in HP/UX which randomly hung or crashed /bin/sh in a way to make the tty locked and unuseable. Sure, I get that. I wager that there are comparatively few people who will assume this is an implementation

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:40, Chet Ramey wrote: > > On 4/9/25 9:31 AM, Dan Shelton wrote: > > On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > >> > >> On 4/9/25 2:09 AM, Cedric Blancher wrote: > >>> Good morning! > >>> > >>> C

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > > On 4/9/25 2:09 AM, Cedric Blancher wrote: > > Good morning! > > > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > I implemented it back in 2023 and it will be in bash-5.3. Thank you. I like the x=${

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > > On 4/9/25 2:09 AM, Cedric Blancher wrote: > > Good morning! > > > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > I implemented it back in 2023 and it will be in bash-5.3. > > There was quite a

Re: Support ksh93 x=${cmd;}

On 4/9/25 2:09 AM, Cedric Blancher wrote: Good morning! Could bash please support x=${cmd;} alongside x=$(cmd)? I implemented it back in 2023 and it will be in bash-5.3. There was quite a long discussion about it: https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html -- ``The

Re: Support ksh93 x=${cmd;}

Cedric Blancher writes: > Good morning! > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > x=$(cmd;} works like x=$(cmd), except that cmd does not run in > a subshell, i.e. the stdout within ${cmd;} is redirected to the > variable "x", but any oth

Support ksh93 x=${cmd;}

Good morning! Could bash please support x=${cmd;} alongside x=$(cmd)? x=$(cmd;} works like x=$(cmd), except that cmd does not run in a subshell, i.e. the stdout within ${cmd;} is redirected to the variable "x", but any other changes of variables (global/static/local) are also availab

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

URL: <https://savannah.gnu.org/bugs/?66923> 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:

Re: bash doesn't build with gcc 14.x

ashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory -lti

Re: bash doesn't build with gcc 14.x

On 12/6/24 10:24 PM, Yuri Kanivetsky wrote: Meanwhile the workaround is: ./configure CFLAGS=-Wno-implicit-function-declaration && make Since you're building in a docker container, or, more specifically, without ncurses or any kind of termcap/termlib support, it might be better to run

Re: bash doesn't build with gcc 14.x

On 12/6/24 7:50 PM, Yuri Kanivetsky wrote: gcc 14.1.0 turned -Wimplicit-function-declaration into an error: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=55e94561e97ed0bce4774aa1c6b5d5d82209a379 Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: bash doesn't build with gcc 14.x

Meanwhile the workaround is: ./configure CFLAGS=-Wno-implicit-function-declaration && make

bash doesn't build with gcc 14.x

gcc 14.1.0 turned -Wimplicit-function-declaration into an error: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=55e94561e97ed0bce4774aa1c6b5d5d82209a379 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a1adce82c17577aeaaf6b9736ca8a1455d1164cb The bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi

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

On 11/18/24 12:55 AM, Martin D Kealey wrote: On Sun, 17 Nov 2024, 03:32 Chet Ramey, > wrote: On 11/16/24 3:36 AM, Martin D Kealey wrote: I don't think a disclaimer saying "this manual is not what it does not claim to be" is particularly useful. That's

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

On Monday, November 18, 2024, Martin D Kealey wrote: > > That's valid, but how else do we get people to read the correct document > for their skill level, How is it our responsibility? > I've used Bash for about 30 years, and even I have to wonder whether the > Shell manual should start with t

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

On Sun, 17 Nov 2024, 03:32 Chet Ramey, wrote: > On 11/16/24 3:36 AM, Martin D Kealey wrote: > I don't think a disclaimer saying "this manual is not what it does not > claim to be" is particularly useful. > That's valid, but how else do we get people to read the correct document for their skill l

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

On 11/16/24 3:36 AM, Martin D Kealey wrote: (Insert this between the "Copyright" and "Description" sections) I don't think a disclaimer saying "this manual is not what it does not claim to be" is particularly useful. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

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

On Sat, 16 Nov 2024 at 15:01, Robert Elz wrote: > Date:Sat, 16 Nov 2024 14:05:17 +1000 > From:Martin D Kealey > Message-ID: d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com> > > | I know, but "explicitly" is not the same as "highlighted", let alone > "well > | enough".

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

On Saturday, November 16, 2024, Martin D Kealey wrote: > (Insert this between the "Copyright" and "Description" sections) > > > *“PrefaceDear reader, if this is your introduction to the Shell programming > language, please be aware that although it may look like other languages > you are familiar

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

Date:Sat, 16 Nov 2024 14:05:17 +1000 From:Martin D Kealey Message-ID: | I know, but "explicitly" is not the same as "highlighted", let alone "well | enough". Please, nothing at all like you're suggesting. Man pages are not, and not intended to be, tutorials.

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

On Fri, 15 Nov 2024 at 00:20, Chet Ramey wrote: > On 11/13/24 11:40 PM, Martin D Kealey wrote: > > > The fact that pipeline components are implicitly run in subshells is > > arguably not highlighted well enough [...] > > The man page states that explicitly. > I know, but "explicitly" is not th

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

aidd , thxx .. ++ On Thu, Nov 14, 2024, 8:45 PM Chet Ramey wrote: > On 11/14/24 2:28 PM, #!microsuxx wrote: > > maybe set -a 'd help ? > > if it can backwards export the vars > > No. A child process can't affect its parent's environment without inventing > some kind of IPC. > > -- > ``The lyf so

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

On 11/14/24 2:28 PM, #!microsuxx wrote: maybe set -a 'd help ? if it can backwards export the vars No. A child process can't affect its parent's environment without inventing some kind of IPC. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita bre

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

maybe set -a 'd help ? if it can backwards export the vars On Thu, Nov 14, 2024, 3:01 PM Chet Ramey wrote: > On 11/13/24 4:48 PM, Yuri wrote: > > > The first 'source' command didn't set variables set or exported in the > > child.sh script, even though 'source' is executed in the current > script

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

On 11/13/24 11:40 PM, Martin D Kealey wrote: The fact that pipeline components are implicitly run in subshells is arguably not highlighted well enough, but it IS stated that all components of a pipeline run in parallel, so it is logically deducible that this must involve separate processes. Th

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

On 11/13/24 5:12 PM, Yuri wrote: On 11/13/24 14:02, Greg Wooledge wrote: The commands within a pipeline are executed in subshells (child processes), so all variable changes are discarded when the subshell exits. This sounds like an implementation detail that should be invisible that affects

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

On 11/13/24 4:48 PM, Yuri wrote: The first 'source' command didn't set variables set or exported in the child.sh script, even though 'source' is executed in the current script's context, The `source' command isn't "executed in the current script's context." It is executed in a subshell, whic

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

Hi Martin, On 11/13/24 20:40, Martin D Kealey wrote: If you need to separate the output of `set -x` from your script's other output, consider setting BASH_XTRACEFD: exec 3>> /path/to/xtrace-logfile.txt BASH_XTRACEFD=3 set -x source your_file set +x exec 3>&- I

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

y not highlighted well enough, but it IS stated that all components of a pipeline run in parallel, so it is logically deducible that this must involve separate processes. If you need to separate the output of `set -x` from your script's other output, consider setting BASH_XTRACEFD: exec 3&

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

Date:Thu, 14 Nov 2024 00:30:32 +0100 From:"#!microsuxx" Message-ID: | i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to | tty , or restore from saved Assuming that this is even slightly relevant to the question here (whether any of thi

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

another code is if u wanna not use . or eval or bash cmd ( . is source ) shopt -s expand_aliases alias script=" $( < user.bash ) " script On Thu, Nov 14, 2024, 1:10 AM #!microsuxx wrote: > also u need to $log > may i ask what criteria ur scripts are about > > a $log can be > > log=/tmp/my.log.

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

This script: #!/usr/bin/env bash # write child script echo "export XVAR=xx" > child.sh echo "YVAR=yy" >> child.sh # 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" prints th

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 output in case it would execute > "exit 1" Then don't

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

i agree its hard to , say , comm clearly together i suggest for next times more real life true examples op's msgs werent so much detailed , more bla-neric :)) greets all On Thu, Nov 14, 2024, 1:35 AM Robert Elz wrote: > Date:Wed, 13 Nov 2024 15:18:58 -0800 > From:Yuri

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

Date:Wed, 13 Nov 2024 15:18:58 -0800 From:Yuri Message-ID: | 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 late

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

also u need to $log may i ask what criteria ur scripts are about a $log can be log=/tmp/my.log.$USER.$SRANDOM On Thu, Nov 14, 2024, 1:04 AM #!microsuxx wrote: > maybe ur email formats it wrong > those are two lines , by greg > not one > > anyway if u append more than one cmd to logfile > more

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

maybe ur email formats it wrong those are two lines , by greg not one anyway if u append more than one cmd to logfile more than one source cmd u need to use >>logfile instead of >logfile On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote: > > > On Thu, Nov 14, 2024, 12:57 AM Yuri wrote: > >> On 1

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

On Thu, Nov 14, 2024, 12:57 AM 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 output in case it would > execute "exit 1" > the >logfile makes

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

produce log2 ? > > i thought ur looking for errors and for this set -x and stderr ? no need > for both ? > > i need some details clarified .. > > On Thu, Nov 14, 2024, 12:48 AM Yuri wrote: > >> Hi !microsuxx, >> >> >> But I need to save the outpu

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

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 output in case it would execute "exit 1" Yuri

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

u need to , save out of . script1 to log1 but what was your second sentense alike of this first one ? u run source over log1 to produce log2 ? i thought ur looking for errors and for this set -x and stderr ? no need for both ? i need some details clarified .. On Thu, Nov 14, 2024, 12:48 AM Yuri

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

24 15:36, #!microsuxx wrote: what u need to do with the vars include all code in tee or try exec > >( tee -a log ) 2>&1 set -x . my.bash ... what i firstly meant : #!/bin/bash tee -a log < <( all code here set -x ; . code ; other code that needs the vars set maybe needs

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

if u dont need stderr even simpler On Thu, Nov 14, 2024, 12:36 AM #!microsuxx wrote: > what u need to do with the vars > include all code in tee > or try > > exec > >( tee -a log ) 2>&1 > set -x > . my.bash > ... > > what i firstly meant : > &g

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

what u need to do with the vars include all code in tee or try exec > >( tee -a log ) 2>&1 set -x . my.bash ... what i firstly meant : #!/bin/bash tee -a log < <( all code here set -x ; . code ; other code that needs the vars set maybe needs a 2> smth ) try ( set

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

another solution if u parse output u can intercept and parse without piping exec 2> >( stderr_parser_cmd ) 1> >( stdout parser cmd ) or both in one or or another one : exec >>log 2>&1 set -x . cmd i just dunno the exec cmd to bring back the fd 1 and 2 after usage

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

On 11/13/24 14:48, #!microsuxx wrote: 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd tee < <( . foo ; cmds ) 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

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

source is not tty dependand , so try .. tee -a log < <( exec 2>&1 set -x . user.bash ) On Wed, Nov 13, 2024, 11:52 PM Yuri wrote: > On 11/13/24 14:45, #!microsuxx wrote: > > depending on actual purpose instead bs demo code , there are serval > > approaches to

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

eg in ur puroose u dont need source and in ur code when u understood | othercmd is in another subshell , u see it doesnt well if u pipe to tee , .. well the scope of needed 1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd tee < <( . foo ; cmds ) On Wed, Nov 13, 2024, 11:45 PM

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

On 11/13/24 14:45, #!microsuxx wrote: depending on actual purpose instead bs demo code , there are serval approaches to code running code The original code in my project runs 'source x.sh > log' where x.sh is some user-provided script. I wanted to trace the code using 's

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

depending on actual purpose instead bs demo code , there are serval approaches to code running code On Wed, Nov 13, 2024, 11:13 PM Yuri wrote: > On 11/13/24 14:02, Greg Wooledge wrote: > > The commands within a pipeline are executed in subshells (child > > processes), so all variable changes are

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

On 11/13/24 14:02, Greg Wooledge wrote: The commands within a pipeline are executed in subshells (child processes), so all variable changes are discarded when the subshell exits. This sounds like an implementation detail that should be invisible that affects how the 'source' feature works. T

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: 5.3-alpha: less readable output when set -x

> This is from https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00092.htm > l > > It ensures e.g. that control characters are always displayed in a > printable manner. so that is definitely intentional and everything is now clear to me thanks a lot for your time ciao -gabriele

Re: 5.3-alpha: less readable output when set -x

On 4/24/24 11:34 AM, baldu...@units.it wrote: Note the difference in how the argument to the function is output. In the case of bash-5.3-alpha the syntax of the argument is correct (ie if I call the show function with $'\n1\n2\n3\n' everything works as expected), but is less readable (and this

Re: 5.3-alpha: less readable output when set -x

On Wed, Apr 24, 2024 at 11:35 AM wrote: > > hello > > Apologies if I am missing some blatant point here > > I have noticed a difference in behavior of bash-5.2.26 and > bash-5.3-alpha which isn't a problem of correctness, but may be wasn't > intentional(?) This is from https://lists.gnu.org/archi

Re: 5.3-alpha: less readable output when set -x

nal(?) > > Given the scriptlett: > > 8< > #!/bin/sh > set -x > > show () { > cat < $1 > EOF > return 0 > } > > show " > 1 > 2 > 3 > " > exit 0 > 8< > > for me the output

5.3-alpha: less readable output when set -x

hello Apologies if I am missing some blatant point here I have noticed a difference in behavior of bash-5.2.26 and bash-5.3-alpha which isn't a problem of correctness, but may be wasn't intentional(?) Given the scriptlett: 8< #!/bin/sh set -x show () { cat <

Re: [PATCH] fix [[ -t X ]] segfault

On 9/8/23 12:36 PM, Grisha Levit wrote: Since the change that made `test -t FD' report an error for non-numeric values of FD: $ [[ -t X ]] bash: [[: X: integer expected Segmentation fault Thanks for the report and patch. Chet -- ``The lyf so short, the craft so long to lerne.'&

[PATCH] fix [[ -t X ]] segfault

Since the change that made `test -t FD' report an error for non-numeric values of FD: $ [[ -t X ]] bash: [[: X: integer expected Segmentation fault Below patch wraps all [[ test execution in a new function that provides a jump target and returns an exit status usable directly by the cond

Re: key "x" doesn't print out the "x", only "CTRL-V x" does.

On 9/7/23 8:17 AM, detlef.bier...@posteo.de wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When pressing the "x" key, no letter appears, with the combination "CTRL-v x" the "x" appears. The key only works in bash, in sh, in the X

key "x" doesn't print out the "x", only "CTRL-V x" does.

-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When pressing the "x" key, no letter appears, with the combination "CTRL-v x" the "

Re: set -x vs. n=($@)

OK. That's well and good. But my main problem now is that that fact is not documented anywhere. (Also here it is again, so as to remove any confusion about "compound assignment" (some readers might think it meant two ='s on the same line.) $ bash -c 'set a b c; set -x;

Re: set -x vs. n=($@)

On 9/3/23 6:08 AM, Dan Jacobson wrote: It's not fair: set -x a b c m=$@ n=($@) == gives == + m='a b c' + n=($@) It's because the compound assignment forces the expansion to be deferred. You have to figure out what kind of array you're dealing with, for example,

Re: set -x vs. n=($@)

On 9/3/23 12:15 PM, Lawrence Velázquez wrote: However... bash-5.2$ declare -a c=("$a") + c=('foo') + declare -a c You kind of have to. This isn't an assignment statement, since `declare' is a builtin and its arguments have to be expanded

Re: set -x vs. n=($@)

On Sun, Sep 3, 2023, 20:57 Greg Wooledge wrote: > On Sun, Sep 03, 2023 at 08:39:25PM +0200, alex xmb ratchev wrote: > > On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote: > > > > > It's not fair: > > > set -x a b c > > > > > > > you may w

Re: set -x vs. n=($@)

On Sun, Sep 03, 2023 at 08:39:25PM +0200, alex xmb ratchev wrote: > On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote: > > > It's not fair: > > set -x a b c > > > > you may want -v *Sigh* No. set -v shows lines as they are being READ by the shell. set -x shows

Re: set -x vs. n=($@)

On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote: > It's not fair: > set -x a b c > you may want -v m=$@ n=($@) > == gives == > + m='a b c' > + n=($@) > please either say > + m=$@ > + n=($@) > or better: > + m='a b c' > + n=('a&#

Re: set -x vs. n=($@)

html > the special exception. This behavior is not specific to $@. bash-5.2$ a=foo bash-5.2$ set -x bash-5.2$ b=("$a") + b=("$a") However... bash-5.2$ declare -a c=("$a") + c=('foo') + declare -a c -- vq

set -x vs. n=($@)

It's not fair: set -x a b c m=$@ n=($@) == gives == + m='a b c' + n=($@) please either say + m=$@ + n=($@) or better: + m='a b c' + n=('a' 'b' 'c') or metion on https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html the special exception. GNU bash, version 5.2.15

Re: [PATCH] fix bind -X quoting

e of a key binding itself. [...] This would allow us, for instance, to really go wild and make `bind -X' display a series of `bind -x' commands to recreate the macro bindings. I'm unlikely to be doing any of the work, but big +1 on this. This would be a valuable inspection and trou

Re: [PATCH] fix bind -X quoting

> This would allow us, for instance, to really go wild and make `bind > -X' display a series of `bind -x' commands to recreate the macro > bindings. I'm unlikely to be doing any of the work, but big +1 on this. This would be a valuable inspection and troubleshooting tool. (

Re: [PATCH] fix bind -X quoting

On 7/31/23 9:30 AM, Chet Ramey wrote: On 7/26/23 5:57 PM, Grisha Levit wrote: It's just not transitive. Another issue I didn't think of with printing the unquoted translated command is that it can include newlines, which is a problem since you have to read the `bind -X' outpu

Re: [PATCH] fix bind -X quoting

On 7/26/23 5:57 PM, Grisha Levit wrote: It's just not transitive. Another issue I didn't think of with printing the unquoted translated command is that it can include newlines, which is a problem since you have to read the `bind -X' output one line at a time to reuse it with

Re: [PATCH] fix bind -X quoting

On Wed, Jul 26, 2023, 16:06 Chet Ramey wrote: > > On 7/24/23 1:13 PM, Chet Ramey wrote: > > > You could do it if you allowed, say > > > > bind -x '"\eX": \"command with spaces\" \"x\"' > > > > and then stripped the b

Re: [PATCH] fix bind -X quoting

On 7/24/23 1:13 PM, Chet Ramey wrote: You could do it if you allowed, say bind -x '"\eX": \"command with spaces\" \"x\"' and then stripped the backslashes before calling rl_generic_bind, but that's not exactly backwards compatible either. Thinkin

Re: [PATCH] fix bind -X quoting

On Mon, Jul 24, 2023, 7:13 PM Chet Ramey wrote: > On 7/19/23 12:47 PM, Grisha Levit wrote: > > On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: > >> Thanks for the report. It seems like your patch is incomplete, though. > >> After applying it: > >> > >

Re: [PATCH] fix bind -X quoting

On 7/19/23 12:47 PM, Grisha Levit wrote: On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: Thanks for the report. It seems like your patch is incomplete, though. After applying it: $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo "x&q

Re: [PATCH] fix bind -X quoting

On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: > Thanks for the report. It seems like your patch is incomplete, though. > After applying it: > > $ bind -x '"\eX": echo "x"' > $ bind -X > "\eX": "echo "x"&quo

Re: [PATCH] fix bind -X quoting

t the best fix, though I doubt it will impact any > > real usage. > > Thanks for the report. It seems like your patch is incomplete, though. > After applying it: > > $ bind -x '"\eX": echo "x"' > $ bind -X > "\eX": "echo "

Re: [PATCH] fix bind -X quoting

seems like your patch is incomplete, though. After applying it: $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo "x"" We probably need to suppress printing the double quotes around `out' if print_readably < 0. -- ``The lyf so s

[PATCH] fix bind -X quoting

The output of `bind -X' is not reusable if the bound command has quotes, backslashes, etc. $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo \"x\"" $ bind -x "$(bind -X)" $ bind -X "\eX": "echo \\\&

Re: [PATCH] unwind protect for bind -x commands

On 6/27/23 6:47 PM, Grisha Levit wrote: If SIGINT is received during the execution of a bind -x command, the memory allocated for the saved parser state is leaked and the READLINE_* variables remain in the environment Thanks for the report and fix. Chet -- ``The lyf so short, the craft so

[PATCH] unwind protect for bind -x commands

If SIGINT is received during the execution of a bind -x command, the memory allocated for the saved parser state is leaked and the READLINE_* variables remain in the environment * pcomplete.c,bashline.c: - uw_restore_parser_state,uw_rl_set_signals: move from pcomplete.c to bashline.c

Re: bash 5.2 bad substitution for ${x:+${x}[}

On 10/20/22 5:03 AM, Martin von Gagern wrote: Bash Version: 5.2 Patch Level: !PATCHLEVEL! Release Status: release Description: Some substitutions that used to work pre 5.2 are failing starting in 5.2. I did a git bisect on that, it's the initial 5.2 commit which broke this, https://git.savann

bash 5.2 bad substitution for ${x:+${x}[}

e in this position. Repeat-By: bash -c 'x=""; echo "a${x:+${x}[}b"' Work-around: Omit the inner curly braces, i.e. use "a${x:+$x[}b".

Re: [PATCH] 4.3..devel: Fix printf %d "'X" affected by intermediate mbstate_t

On 9/24/22 9:15 PM, Koichi Murase wrote: Bash Version: 4.4 Patch Level: 12 Release Status: release Description: With a multi-byte encoding that has a non-trivial intermediate state (mbstate_t), « printf %d "'" » can be affected by the internal mbstate_t of `mbtowc'/`mblen' to produce

[PATCH] 4.3..devel: Fix printf %d "'X" affected by intermediate mbstate_t

[i.e., Unicode characters outside Basic Multilingual Plane (BMP) whose code points are larger than U+] in a UTF-8 locale in Cygwin and MSYS2, in which sizeof(wchar_t) == 2. For example, consider the following command: $ printf '<%x>' $'"\U1F6D1'{

Re: How come math/arithmetic cannot work by set -x

On 8/12/22 8:22 PM, Dennis Williamson wrote: set -x; unset a; b=2; c=7; ((a = b + c)); echo "$a $b $c"; set +x + unset a + b=2 + c=7 + (( a = b + c )) + echo '9 2 7' 9 2 7 + set +x without the dollar signs doesn't. "Within an expression, shell variables ma

Re: How come math/arithmetic cannot work by set -x

On 8/12/22 7:27 PM, Budi wrote: How come math/arithmetic ((i=k+l)) cannot make use of set -x If you're talking about what I think you are, because that's not how `set -x' works. It's the same reason that k=2+3 echo $(( $k*5 )) echo $(( k*5 )) produces two different num

Re: How come math/arithmetic cannot work by set -x

On Sat, Aug 13, 2022 at 06:51:04AM +0700, Budi wrote: > It doesn't work means no use on set -x, no value is shown set -x shows the command being executed, with arguments expanded. unicorn:~$ cat foo #!/bin/bash set -x a=5 b=7 c=$((a * b)) echo "$c" unicorn:~$ ./foo + a=5 + b=

Re: How come math/arithmetic cannot work by set -x

On Fri, Aug 12, 2022, at 7:40 PM, Dennis Williamson wrote: > It works for me. What are you expecting? > > It would help if you show what you're doing, the result you're getting and > what you expect instead. I'm guessing that instead of, for example % bash -x

Re: How come math/arithmetic cannot work by set -x

On Fri, Aug 12, 2022 at 6:51 PM Budi wrote: > It doesn't work means no use on set -x, no value is shown > > On 8/13/22, Dennis Williamson wrote: > > On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > > > >> How come math/arithmetic ((i=k+l)) cannot make use of set

Re: How come math/arithmetic cannot work by set -x

It doesn't work means no use on set -x, no value is shown On 8/13/22, Dennis Williamson wrote: > On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > >> How come math/arithmetic ((i=k+l)) cannot make use of set -x >> >> Please help.. >> (so annoying). >> >

Re: How come math/arithmetic cannot work by set -x

On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > How come math/arithmetic ((i=k+l)) cannot make use of set -x > > Please help.. > (so annoying). > It works for me. What are you expecting? It would help if you show what you're doing, the result you're getting and what

How come math/arithmetic cannot work by set -x

How come math/arithmetic ((i=k+l)) cannot make use of set -x Please help.. (so annoying).

Signed integer overflow in ansicstr() when parsing \x{...}

: 16 Release Status: release Description: Parsing very long \x{...} sequences inside $''-strings triggers signed integer overflow, which is undefined behavior. Repeat-By: $ ./configure CFLAGS='-g -Og -fsanitize=undefined' ... $ make ... $ ./bash -n

Re: Inconsistency between fc and C-x C-e

On Fri, Jun 10, 2022, at 10:19 AM, Chet Ramey wrote: > I didn't look at more than mailx, but the description there makes it clear > that $EDITOR needs to expand to a command name. `more' has similar wording > ("The name of the editor shall be taken from the environment variable > EDITOR.") and talk

  1   2   3   4   5   6   >