Re: bash loses control of jobs inside a command substitution
This seems more like a race condition, see:
$ f() { ( sleep 0.1; exit 13 ) & "$@"; wait -n; echo $?; }
$
$ f sleep 0.0
[1] 30612
[1]+ Exit 13 ( sleep 0.1; exit 13 )
13
$ f sleep 0.2
[1] 30617
[1]+ Exit 13 ( sleep 0.1; exit 13 )
127
Re: bash loses control of jobs inside a command substitution
Behavior of wait -n differs on interactive and non-interactive sessions
though, maybe this really is a bug
$ bash -ic '( ( sleep 0.1; exit 13 ) & sleep 0; wait -n; echo $? )'
0
$ bash -c '( ( sleep 0.1; exit 13 ) & sleep 0; wait -n; echo $? )'
13
On Wed, Nov 20, 2019 at 1:01 PM Oğuz wrote:
> This seems more like a race condition, see:
>
> $ f() { ( sleep 0.1; exit 13 ) & "$@"; wait -n; echo $?; }
> $
> $ f sleep 0.0
> [1] 30612
> [1]+ Exit 13 ( sleep 0.1; exit 13 )
> 13
> $ f sleep 0.2
> [1] 30617
> [1]+ Exit 13 ( sleep 0.1; exit 13 )
> 127
>
Re: Locale not Obeyed by Parameter Expansion with Pattern Substitution
On 11/17/19 4:25 AM, Chris Carlen wrote:
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
UTF-8 multibyte char string split into bytes rather than characters.
Repeat-By:
#!/bin/bash
shopt -s extglob
LC_ALL="en_US.UTF-8"
# E.g., normal/expected behavior:
# Create a string:
A=abc
# Replace left virtual empty strings with spaces, putting separated
# chars into positional parameters, then print them quoted:
set -- ${A//?()/ }
echo "${@@Q}" #-> 'a' 'b' 'c'
# E.g., abnormal behavior:
# write 'REVERSE PILCROW SIGN' to B, then repeat as above:
printf -v B '\u204B'
set -- ${B//?()/ }
echo "${@@Q}" #-> $'\342' $'\201' $'\213'
Yes, this is a problem. The null match requires advancing through the
string by one character, instead of one byte. I'll fix 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/
Re: bash loses control of jobs inside a command substitution
Date:Tue, 19 Nov 2019 16:51:12 -0300 From:Luiz Angelo Daros de Luca Message-ID: | And two related features requests: 1) It seems that pids args are ignored | by wait when '-n' is specified. However, it would be a nice add_on to use | the list of pids as a filter. 2) 'wait -n' lacks a way to get dead child | PID, requiring some race conditions techniques to get it. Both of those are in the NetBSD sh (not currently available other than as the /bin/sh in NetBSD .. the sources are available but are not easy to build in any other environment, yet). I have suggested the addition of both (#2 uses a -p var option to wait, which then places the pid of the porcess that exited in var) to Chet - and last I heard, he was considering them. oguzismailuy...@gmail.com said: | Behavior of wait -n differs on interactive and non-interactive sessions | though, maybe this really is a bug I haven't looked at the example code closely enough to comment on the original report, but different behaviour in this area for interactive and non-interactive shells is expected. Interactive shells wait for background processes by default (because users typically don't race around typing "wait" commands) and simply clean them up whenever one finishes. Interactive shells don't, so scripts can actually get the status of previously started background processes. So the difference noticed is probably not relevant to the original issue. kre
Re: bash loses control of jobs inside a command substitution
On 11/19/19 2:51 PM, Luiz Angelo Daros de Luca wrote: Hello, Normally 'wait -n' will return the exit code of background process when they terminate before wait is runned. However, when bg processes and 'wait -n' runs inside a command substitution, bash loses control of bg process as soon as they exit. This looks a lot like a race condition. If you run the sleep with a non-zero argument (or, really, even if you don't, but the non-zero sleep increases the odds), you have two chances -- the sleep and the command substitution in the second loop -- for child processes to exit and be reaped. Since they're asynchronous children, bash will save their statuses, but they won't be available for a subsequent `wait -n' call. They're not lost: you can fetch those statuses using wait with a pid argument. The difference is when jobs are moved from the `active jobs' list, where they are available to `wait -n', into the `saved background processes' list, where they are not, and that does differ based on whether the shell thinks it will eventually notify the user about the job's exit status. When the shell is started to run a command substitution, it knows it will not have to notify the user about any jobs, so it's more aggressive about moving jobs out of the jobs list. 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/
Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?
It's quite common for people to press CTRL-C to discard the current command line. This is harmless actually for most times except when people include $? in $PS1. I also show $? in red color when it's not 0 so it's more noticeable. So is it OK to not change $? when people are pressing CTRL-C to discard the input? -clark
Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?
Date:Thu, 21 Nov 2019 10:27:08 +0800 From:Clark Wang Message-ID: | So is it OK to not change $? when people are pressing CTRL-C to | discard the input? I would say not only "OK" but "required" - $? should only ever be changed as a result of command execution (or attempted execution in case the exec, or redirection, or something, fails). Even if there's a SIGINT trap handler that runs commands, $? should not be being altered merely as a result of a SIGINT, only when that SIGINT causes a command to abort, in which case that command's exit status (which will be 128+SIGINT .. typically 130 .. when the SIGINT wasn't caught by the application) should $? be altered. Of course, Chet might disagree... kre
