Re: printf -u "$fd"?
On Wed, May 22, 2024 at 12:32 AM Zachary Santer wrote:
>
> In my Rocky Linux 9.1 VM:
> $ bash --version
> GNU bash, version 5.1.8(1)-release [...]
> $ exec {fd_A}> >( cat > file_A.txt )
> $ exec {fd_B}> >( cat > file_B.txt )
> $ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}"
> words
> $ exec {fd_A}>&- {fd_B}>&-
> $ cat file_A.txt
> words
> $ cat file_B.txt
> words
> $ exec {fd_A}> >( tr 'w' 'W' > file_A.txt )
> $ exec {fd_B}> >( tr 'w' 'W' > file_B.txt )
> $ exec {fd_A}>&- {fd_B}>&-
> $ cat file_A.txt
> $ cat file_B.txt
> $
Yes, I missed a line there, several times actually, and then pasted that here.
$ exec {fd_A}> >( cat > file_A.txt )
$ exec {fd_B}> >( cat > file_B.txt )
$ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}"
words
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
words
$ cat file_B.txt
words
$ exec {fd_A}> >( tr 'w' 'W' > file_A.txt )
$ exec {fd_B}> >( tr 'w' 'W' > file_B.txt )
$ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}"
words
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
Words
$ cat file_B.txt
Words
I should really sit on these emails more often.
Re: [PATCH] execute-named-command: fix small leaks
On 5/21/24 11:32 AM, Grisha Levit wrote: - free command if it is the empty string - free command before calling bound function, in case bound function does not return, like rl_abort Thanks for the report. I don't want to ring the bell if the command is the empty string, so I did this slightly differently. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] bashline: small leaks
On 5/21/24 11:34 AM, Grisha Levit wrote: - free directory_part when completing command words like `~/bin/' - free contents of matches when completing command words in old-style command substitutions Thanks for the report and patch. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: printf -u "$fd"?
On 5/22/24 12:32 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 3:06 PM Chet Ramey wrote: On 5/21/24 11:14 AM, Zachary Santer wrote: On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: On 5/21/24 6:17 AM, Zachary Santer wrote: I was wondering what the relationship between the devel and master branches was. No mystery: the devel branch captures ongoing development, gets the latest bug fixes, and is where new features appear. The master branch is for stable releases. But the devel branch won't get changes for bash versions beyond what's in alpha right now? I'm genuinely curious how you got that from what I said, especially since devel has gotten changes since I released bash-5.3-alpha. Changes I assumed would make it into master while master is bash-5.3. It sounded like you didn't want to implement anything in devel right now that wasn't going to make it into bash-5.3. I probably didn't phrase that very well. I'm not planning on including any additional new features in bash-5.3 beyond what's in alpha now. If I do some work on new features -- I don't usually, I try to spend my time on bug fixes and release engineering -- I'll do it in a private branch that doesn't get merged until after bash-5.3 is released. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] dynamic-complete-history: avoid null ptr qsort UB
On 5/21/24 11:58 PM, Grisha Levit wrote: $ HISTFILE= bash --norc -in <<< $'#\n#\e\t' bashline.c:3720:16: runtime error: null pointer passed as argument 1, which is declared to never be null /usr/include/stdlib.h:971:30: note: nonnull attribute specified here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior bashline.c:3720:16 Interesting that this has never actually hit since 1991 when dynamic history completion was implemented. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] spell-correct-word: avoid inf loop with neg arg
On 5/21/24 10:41 PM, Grisha Levit wrote: bash --norc -in <<< $'A \e-\cXs' I think I'd rather make negative counts work in the opposite direction. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
sh vs. bash -xc 'a=b c=$a'
It seems these should both make one line "+ a=b c=b" output, for s in sh bash do $s -xc 'a=b c=$a' done I mean they give the same results, but bash splits it into two lines, so the user reading the bash -x output cannot tell if one (correct) or two (incorrect) lines were used. They can tell with sh -x. By the way, I looked up and down the man page, and wasn't sure if it says one should expect $c to end up as c= or c=b in fact! And I'm not sure the man page says to expect two lines or one of -x output either, when using sh vs. bash.
Re: sh vs. bash -xc 'a=b c=$a'
On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: > It seems these should both make one line "+ a=b c=b" output, > > for s in sh bash > do $s -xc 'a=b c=$a' > done > > I mean they give the same results, but bash splits it into > two lines, so the user reading the bash -x output cannot tell > if one (correct) or two (incorrect) lines were used. > They can tell with sh -x. Does it actually matter? What makes bash's output "incorrect", exactly? > By the way, I looked up and down the man page, > and wasn't sure if it says one should expect > $c to end up as c= or c=b in fact! I don't know where it's documented, but assignments and expansions are always performed left to right. In your example, a value is assigned to variable a before $a is expanded. > And I'm not sure the man page says to expect two lines or one of -x > output either, when using sh vs. bash. I don't see why it matters. The purpose of the -x output is to show you what the shell is doing, so that you can debug your script. As long as the output is *clear*, it's doing its job. In bash's case, hobbit:~$ bash -xc 'a=b c=$a' + a=b + c=b you can very easily see the order in which the assignments happen, and the values that are assigned.
Re: sh vs. bash -xc 'a=b c=$a'
Greg Wooledge wrote in : |On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: |> It seems these should both make one line "+ a=b c=b" output, |> |> for s in sh bash |> do $s -xc 'a=b c=$a' Only to note that this is not portable. The FreeBSD shell will not assign "b" to "c" for this one! |> done |> |> I mean they give the same results, but bash splits it into |> two lines, so the user reading the bash -x output cannot tell |> if one (correct) or two (incorrect) lines were used. |> They can tell with sh -x. | |Does it actually matter? What makes bash's output "incorrect", exactly? | |> By the way, I looked up and down the man page, |> and wasn't sure if it says one should expect |> $c to end up as c= or c=b in fact! | |I don't know where it's documented, but assignments and expansions are |always performed left to right. In your example, a value is assigned |to variable a before $a is expanded. | |> And I'm not sure the man page says to expect two lines or one of -x |> output either, when using sh vs. bash. | |I don't see why it matters. The purpose of the -x output is to show |you what the shell is doing, so that you can debug your script. As |long as the output is *clear*, it's doing its job. | |In bash's case, | |hobbit:~$ bash -xc 'a=b c=$a' |+ a=b |+ c=b | |you can very easily see the order in which the assignments happen, and |the values that are assigned. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: sh vs. bash -xc 'a=b c=$a'
On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote: > Only to note that this is not portable. > The FreeBSD shell will not assign "b" to "c" for this one! Nor will NetBSD sh. This lets you swap values of two variables without using a third $ x=1 y=2 $ x=$y y=$x $ echo $x $y 2 1 And some Bourne shells expand command substitutions first $ (exit 5) $ x=$? y=`exit 10` $ echo $x 10
Re: sh vs. bash -xc 'a=b c=$a'
Date:Thu, 23 May 2024 05:57:05 +0300 From:=?UTF-8?B?T8SfdXo=?= Message-ID: | On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote: | > Only to note that this is not portable. | Nor will NetBSD sh. That's right, and this is expressly unspecified in POSIX. But I think this aspect is missing the point of the OP's message, which might have been better illustrated without stepping into unspecified behaviour using $SHELL -x -c 'x=1 y=2' I can see the point, this is two var-assigns on a single (empty) command, not two commands, which $SHELL -x -c 'x=1 ; y=2' would be (and which is fully specified to be each fully executed before the next is started, avoiding the other issue). As a comparison consider $SHELL -x -c 'x=1 y=2 :' which the first above is almost equivalent to (the difference is the exit status should there be any command substitutions involved). However, I don't really see that this should matter all that much. (-x output is not specified anywhere, just that it happens). kre
