Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16666
| From | Oğuz <oguzismailuysal@gmail.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Should $(fg) resume a stopped job? |
| Date | 2020-07-31 19:43 +0300 |
| Message-ID | <mailman.394.1596213801.2739.bug-bash@gnu.org> (permalink) |
| References | <CAH7i3Lr72e4Bn3q-Ywn6vnyvT9gx4wTCe6Q9tLAVHV-L7ufhrw@mail.gmail.com> <08840792-f5f6-34b1-ca5a-81e5488eba36@case.edu> <CAH7i3Lozdz2XxHaTkbK+Mp5bBK8KOknF8QhJuPoNbn628ijOvA@mail.gmail.com> |
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
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Should $(fg) resume a stopped job? Oğuz <oguzismailuysal@gmail.com> - 2020-07-31 19:43 +0300
csiph-web