Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15619 > unrolled thread

Re: bash loses control of jobs inside a command substitution

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.

Contents

  Re: bash loses control of jobs inside a command substitution Robert Elz <kre@munnari.OZ.AU> - 2019-11-20 21:54 +0700

#15619 — 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 <luizluca@gmail.com>
    Message-ID:  <CAJq09z4OWeZchYVH9U1G2OuTzdXBh+F8gLEjkqcJemohzi8dDg@mail.gmail.com>

  | 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.

oguzismailuysal@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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web