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

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

Re: Should $(fg) resume a stopped job?

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: Should $(fg) resume a stopped job? Oğuz <oguzismailuysal@gmail.com> - 2020-07-31 19:43 +0300

#16666 — Re: Should $(fg) resume a stopped job?

31 Temmuz 2020 Cuma tarihinde Chet Ramey <chet.ramey@case.edu> yazdı:

> On 7/31/20 2:03 AM, Oğuz wrote:
> >     $ sleep 25
> >     ^Z
> >     [1]+  Stopped                 sleep 25
> >     $
> >     $ echo $(fg; jobs %)
> >     bash: jobs: %: no such job
> >     sleep 25
> >     $
> >     $ jobs
> >     [1]+  Running                 sleep 25 &
> >
> > What I gather from this is that bash fakes interactive job control in
> > command substitution context, because otherwise `fg' wouldn't return
> > immediately. But I don't see any point in that `fg' resumes the stopped
> job
> > when it's faked. Is this a bug or a deliberate choice?
>
> Maybe a minor bug, but certainly a choice. The command substitution keeps
> the jobs list around, since the subshell is supposed to be an exact copy of
> the parent, and it's useful to get the output of `jobs' out of command
> substitution.
>
> You just can't expect to do anything with any of those jobs, since the
> command substitution shell is not the parent of any of them. It would
> make sense to have `fg' complain about that.
>
>
Right, it would. bosh behaves the same way as bash btw.


> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>


-- 
Oğuz

[toc] | [standalone]

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

csiph-web