Re: waiting for process substitutions
On Sat, Oct 12, 2024 at 12:33 PM Oğuz wrote:
>
> On Saturday, October 12, 2024, Zachary Santer wrote:
>>
>> Backwards compatibility with people's expectations
>
> No one expects children of the same parent to be able to wait for eachother.
> It's common sense.
$ ( set -x; : & wait -- "${sibling_pid}" "${!}" ) > >( cat )${
sibling_pid="${!}"; }
+ :
+ wait -- 7088 7089
bash: wait: pid 7088 is not a child of this shell
${sibling_pid} might be a misnomer there, but hopefully this
illustrates my point that the issues you found were resolved by making
other changes. Even if I try to force 'wait' to wait for everything,
this command won't hang.
On Wed, Aug 7, 2024 at 10:27 AM Chet Ramey wrote:
>
> It's trivial to do a lot of things that may cause the shell to hang
> besides trying to wait for a process that will never terminate. What
> should the shell do about those?
Thus my question as to the purpose here.
Re: waiting for process substitutions
On Sun, Jul 14, 2024 at 8:40 PM Zachary Santer wrote:
>
> On Tue, Jul 9, 2024 at 2:37 PM Zachary Santer wrote:
> >
> > On the other hand, do funsubs give us the answer here?
> >
> > shopt -s lastpipe
> > declare -a pid=()
> > command-1 | tee >( command-2 ) ${ pid+=( "${!}" ); } >( command-3 ) ${
> > pid+=( "${!}" ); } >( command-4 ) ${ pid+=( "${!}" ); }
> > wait -- "${pid[@]}"
>
> This absolutely works, so there you go. When expanding multiple
> process substitutions as arguments to a command, you can save the $!
> resulting from each one by following it with an unquoted funsub that
> does that work and doesn't expand to anything.
>
> > That looks obnoxious
>
> I don't mind how it looks. It works.
>
> > declare -a pid=()
> > {
> > commands
> > } {fd[0]}< <( command-1 ) ${ pid+=( "${!}" ); } {fd[1]}< <( command-2
> > ) ${ pid+=( "${!}" ); } {fd[2]}< <( command-3 ) ${ pid+=( "${!}" ); }
> >
> > Do things start breaking?
>
> Yeah, this doesn't work at all
Even that can be made to work by simply removing the space between the
process substitution and the following function substitution. Bash
treats the whole amalgamation as one word. See attached. That was run
by the current devel branch commit: c7439376a3.
Just noticed that, in the second set of procsubs, it looks like bash
is skipping over a potential pid from procsub to procsub. Not sure
what to make of that.
On Wed, Aug 7, 2024 at 12:03 PM Zachary Santer wrote:
>
> What's the purpose of 'wait' without id arguments
> being restricted to the final procsub, then? It sounds like the
> various issues revealed by Oğuz's October 2022 bug report were
> resolved by making other changes.
Backwards compatibility with people's expectations from earlier releases?
At least this is all documented.
zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ ./bash ~/random/procsub-wait-solution true
+ : '5.3.0(1)-beta'
+ wait_explicit_pids=true
+ pid=()
+ declare -a pid
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ : /dev/fd/63 /dev/fd/62 /dev/fd/61 /dev/fd/60
+ SECONDS=0
+ : 'declare -a pid=([0]="6989" [1]="6990" [2]="6991" [3]="6992")' '$!=6992'
+ [[ true == true ]]
+ wait -- 6989 6990 6991 6992
+ : termination status 0 at 8 seconds
+ pid=()
+ printf 'The quick brown fox jumps over the lazy dog.\n'
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ tee -- /dev/fd/63 /dev/fd/62 /dev/fd/61 /dev/fd/60
The quick brown fox jumps over the lazy dog.
+ SECONDS=0
+ : 'declare -a pid=([0]="6994" [1]="6996" [2]="6998" [3]="7000")' '$!=7000'
+ [[ true == true ]]
+ wait -- 6994 6996 6998 7000
++ set +x
overly emphatic : The. Quick. Brown. Fox. Jumps. Over. The. Lazy. Dog.
++ set +x
shouting : THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG.
++ set +x
tortoise, actually : The quick brown fox jumps over the lazy tortoise.
++ set +x
line length : 44
+ : termination status 0 at 8 seconds
+ pid=()
+ fd=()
+ declare -a fd
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ :
+ SECONDS=0
+ : 'declare -a pid=([0]="7003" [1]="7004" [2]="7005" [3]="7006")' '$!=7006'
+ [[ true == true ]]
+ wait -- 7003 7004 7005 7006
+ : termination status 0 at 8 seconds
zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ ./bash ~/random/procsub-wait-solution false
+ : '5.3.0(1)-beta'
+ wait_explicit_pids=false
+ pid=()
+ declare -a pid
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ : /dev/fd/63 /dev/fd/62 /dev/fd/61 /dev/fd/60
+ SECONDS=0
+ : 'declare -a pid=([0]="7008" [1]="7009" [2]="7010" [3]="7011")' '$!=7011'
+ [[ false == true ]]
+ wait
+ : termination status 0 at 2 seconds
+ pid=()
+ printf 'The quick brown fox jumps over the lazy dog.\n'
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ tee -- /dev/fd/63 /dev/fd/62 /dev/fd/61 /dev/fd/60
The quick brown fox jumps over the lazy dog.
+ SECONDS=0
+ : 'declare -a pid=([0]="7013" [1]="7015" [2]="7017" [3]="7019")' '$!=7019'
+ [[ false == true ]]
+ wait
++ set +x
overly emphatic : The. Quick. Brown. Fox. Jumps. Over. The. Lazy. Dog.
+ : termination status 0 at 2 seconds
+ pid=()
+ fd=()
+ declare -a fd
++ sleep 8
++ pid+=("${!}")
++ sleep 6
++ pid+=("${!}")
++ sleep 4
++ pid+=("${!}")
++ sleep 2
++ pid+=("${!}")
+ :
+ SECONDS=0
+ : 'declare -a pid=([0]="7022" [1]="7023" [2]="7024" [3]="7025")' '$!=7025'
+ [[ false == true ]]
+ wait
++ set +x
shouting : THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG.
+ : termination status 0 at 2 seconds
zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ ++ set +x
tortoise, actually : The quick brown fox jumps over the lazy tortoise.
++ set +x
line length : 44
procsub-wait-solution
Description: Binary data
Re: Call dynamic builtins with 'builtin' command
On 10/9/24 7:15 AM, Vadim Nevorotin wrote: Hello! I'm trying to do a very simple task: I want to use the 'stat' builtin from BASH_LOADABLES_PATH without overwriting the current behavior of the 'stat' command in the current shell (whether it's a binary from $PATH, or an alias, or a function). So you want it to override an executable file, since adding a loadable builtin doesn't change the search order, and aliases and shell functions are found before builtins. This does not work: $ builtin stat bash: builtin: stat: not a shell builtin 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 I'm not sure what you expect -- you just disabled the builtin you loaded, so it won't be used. 'enable -n' should just disable stat, according to 'help enable', but it looks like it also removes it. Why should it not? You'll have to enable it again before you use it, which will load it again. So: 1. At least the help for 'enable' should be fixed, but there is definitely a bug in enable+builtin usage for dynamic builtins. What is the bug? 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 enable it use it disable it 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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Fwd: New feature
On Okt 12 2024, Saint Michael wrote: > After using printf, right now I need to lunch a second command if I > need to expand the \n into real new lines. $ printf %b '\n' -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: AW: Re: read command sometimes misses newline on timeout
On 10/7/24 9:49 AM, Thomas Oettli wrote: I agree with you, but it should never happen that read returns timeout, also returns the full line and has already read the newline character. If that happens, there is no way for the script to decide what to do. I think I found the problem and fixed it. It was possible for read to read data immediately before the timeout expired, then check for the timeout before processing the data. It was a very small window, but if you run it through enough iterations, you could hit it. 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/ OpenPGP_signature.asc Description: OpenPGP digital signature
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 > > enable it > use it > disable it Another way would be something like: 1. Save the output of type -p stat in a variable. 2. Enable the builtin. 3. Write a stat() wrapper function that calls either the builtin stat or the external stat program, based on whatever unspecified criteria you are using to switch between the two. If you tell us why you want to switch back and forth between the two implementations within a script, we might be able to give more focused advice.
Re: aliases sometimes not expanded even with expand_aliases set
On 10/12/24 9:31 AM, i...@beware.dropbear.id.au wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: In the following script, the first alias fails with "comand not found" but the second works. This is covered in the manual (bash.1): Bash always reads at least one complete line of input, and all lines that make up a compound command, before executing any of the commands on that line or the compound command. Aliases are expanded when a command is read, not when it is executed. Therefore, an alias definition appearing on the same line as another command does not take effect until the shell reads the next line of input, and an alias definition in a compound command does not take effect until the shell parses and executes the entire compound command. The commands following the alias definition on that line, or in the rest of a compound command, are not affected by the new alias. This behavior is also an issue when functions are executed. Aliases are expanded when a function definition is read, not when the function is executed, because a function definition is itself a command. As a consequence, aliases defined in a function are not available until after that function is executed. -- ``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: AW: Re: read command sometimes misses newline on timeout
On 10/7/24 9:49 AM, Thomas Oettli wrote: I agree with you, but it should never happen that read returns timeout, also returns the full line and has already read the newline character. I don't see how that can happen, given how the code is structured. It's possible for the shell to read all the data on the line and time out before reading the newline, returning the text of the line. The next read reads only a newline, and returns the empty string. But I can't see how that can reproduce your results. Please also see the answer from Martin D Kealey, I think he is on to something: https://lists.gnu.org/archive/html/bug-bash/2024-10/msg7.html lists.gnu.org/archive/html/bug-bash/2024-10/msg7.html> Thanks, I'll look. -- ``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] braces: avoid signed overflow
On 10/1/24 7:18 PM, Grisha Levit wrote:
INTMAX_MAX=9223372036854775807
eval ": {$((INTMAX_MAX-1))..$((INTMAX_MAX))}"
braces.c:447:9: runtime error: signed integer overflow: 9223372036854775807 + 1
cannot be represented in type 'intmax_t' (aka 'long')
Thanks for the report and patch.
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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: waiting for process substitutions
On Saturday, October 12, 2024, Zachary Santer wrote: > > Backwards compatibility with people's expectations No one expects children of the same parent to be able to wait for eachother. It's common sense. -- Oğuz
Re: [PATCH] BASH_SOURCE_FULLPATH_DEFAULT fixup
On 10/3/24 9:56 PM, Grisha Levit wrote: Fix typo in configure.ac causing: src/bash/configure: 3892: test: =: unexpected operator Update shopt reset code to use new define. Thanks for the report and patch. 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/ OpenPGP_signature.asc Description: OpenPGP digital signature
aliases sometimes not expanded even with expand_aliases set
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer uname output: Linux sibyl.beware.dropbear.id.au 6.10.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 12 18:26:09 UTC 2024 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.2 Patch Level: 26 Release Status: release Description: 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='echo' foo x y z shopt expand_aliases alias -p fi alias foo='echo' foo a b c Running it produces: $ ./alias-test.sh ./alias-test.sh: line 7: foo: command not found expand_aliases on alias foo='echo' a b c This is at least, undocumented behaviour. Repeat-By: Run the script in "Description".
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='echo' > foo x y z > shopt expand_aliases > alias -p > fi You've got a compound command there, from "if" to "fi". The parser has to read the entire compound command and parse it before any part of it can be executed. The "foo" alias is not defined at the time the compound command is parsed, so the "foo x y z" line does not undergo the alias expansion. It's parsed as a command named "foo" with three argument words. You'll see the same behavior if you try to define an alias inside a function and then use it in the same function. The function body is a compound command, so it gets parsed all at once. Alias definitions (and anything else that affects parsing, such as the extglob option) should appear outside of compound commands. Personally, if I had to use one, I'd put it in the same place as my function definitions.
Fwd: New feature
From: Saint Michael
Date: Sat, Oct 12, 2024 at 9:49 AM
Subject: New feature
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=$(echo -e "${PROCEDURE_INFO}")
this step would be redundant if printf had the flag.
Philip Orleans
Re: New feature
On Sat, 12 Oct 2024, 23:50 Saint Michael, wrote:
> From: Saint Michael
> Date: Sat, Oct 12, 2024 at 9:49 AM
> Subject: New feature
>
> The command printf needs a new flag, -e, that would mimic that way the
> same flag works with echo.
> …
> PROCEDURE_INFO=$(echo -e "${PROCEDURE_INFO}")
> this step would be redundant if printf had the flag.
>
Do you mean like this:
printf -v PROCEDURE_INFO %b "$other_var"
Though one has to wonder, why is it written as \n to begin with?
-Martin
After using printf, right now I need to lunch a second command…
Mmm, hungry, time for lunch.
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=$(echo -e "${PROCEDURE_INFO}")
> this step would be redundant if printf had the flag.
Use the %b format specifier to expand backslashes in an argument.
hobbit:~$ var='a\tb\040c\x20d'
hobbit:~$ printf '%b\n' "$var"
a b c d
If you want the result in a variable, then:
printf -v newvar %b "$oldvar"
Re: procsub doesn't release the terminal without reading one byte
On 10/9/24 2:01 PM, Oğuz wrote: The first letter I type after running this command won't show up on the terminal: : < <(cat) This is reproducible on 5.3 beta too. It's cat and the scheduler. You have two processes fighting over stdin. cat inherits stdin, and successfully reads one character, because its read returns successfully before readline's pselect returns indicating that there is input and readline calls read. cat tries to write the character to an invalid fd (the pipe is gone), gets -1/EPIPE/SIGPIPE, and dies in the background. Readline calls read and successfully reads the next character. -- ``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: fg via keybind modifies tty settings
On Sat, Oct 12, 2024, at 2:22 AM, David Moberg wrote: > So this kind of bugfix is not enough to ever trigger a new release on its > own? (sounds wise) No, but Chet does periodically release particularly important fixes as patches against the most recent release. (Those make up most of the commits on the "master" branch.) > Is there any cadence to releases Not that I'm aware of. > or any other reason to expect a release at > some point in the future? I believe Chet is getting ready to release 5.3 sooner than later. -- vq
