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


Groups > gnu.bash.bug > #16656

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

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: Should $(fg) resume a stopped job?
Date 2020-07-31 09:17 -0400
Organization ITS, Case Western Reserve University
Message-ID <mailman.376.1596201465.2739.bug-bash@gnu.org> (permalink)
References <CAH7i3Lr72e4Bn3q-Ywn6vnyvT9gx4wTCe6Q9tLAVHV-L7ufhrw@mail.gmail.com> <08840792-f5f6-34b1-ca5a-81e5488eba36@case.edu>

Show all headers | View raw


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.

-- 
``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/

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Should $(fg) resume a stopped job? Chet Ramey <chet.ramey@case.edu> - 2020-07-31 09:17 -0400

csiph-web