Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15617 > unrolled thread
| Started by | Oğuz <oguzismailuysal@gmail.com> |
|---|---|
| First post | 2019-11-20 15:18 +0300 |
| Last post | 2019-11-20 15:18 +0300 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: bash loses control of jobs inside a command substitution Oğuz <oguzismailuysal@gmail.com> - 2019-11-20 15:18 +0300
| From | Oğuz <oguzismailuysal@gmail.com> |
|---|---|
| Date | 2019-11-20 15:18 +0300 |
| Subject | Re: bash loses control of jobs inside a command substitution |
| Message-ID | <mailman.2082.1574252331.13325.bug-bash@gnu.org> |
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 <oguzismailuysal@gmail.com> 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
>
Back to top | Article view | gnu.bash.bug
csiph-web