andrewt@watnow.waterloo.edu (Andrew Thomas) (01/08/90)
I have a simple function:
function restart ()
{
eval `jobs | fgprg $1`
}
which used to work in bash 1.03. It seems now that stuff in `` or $()
gets run in a subshell in 1.04 where there aren't really any jobs. Is
this fixable?
Am I sadly out to lunch on this diagnosis? :-)
--
Andrew Thomas
andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo
"If a million people do a stupid thing, it's still a stupid thing." - Opuschet@cwns1.CWRU.EDU (Chet Ramey) (01/11/90)
In article <ANDREWT.90Jan8091138@watnow.waterloo.edu> andrewt@watnow.waterloo.edu (Andrew Thomas) writes: >It seems now that stuff in `` or $() >gets run in a subshell in 1.04 where there aren't really any jobs. Is >this fixable? It's fixed now; it was broken in 1.03. First of all, stuff in `` or $() always was run in a subshell. I discovered that some bugs we were finding were caused by the fact that subshells retained the same `jobs' structure as their parent. Consider the following case: foo() { more $* } history | foo will always hang because the subshell started to process `foo' is not the parent of the jobs in the job list it inherited from its parent, and it will never get the SIGCHLD signals necessary to flush them out. It was best to simply delete the jobs that were no longer children of the subshell. Chet Ramey -- Chet Ramey Network Services Group "Help! Help! I'm being Case Western Reserve University repressed!" chet@ins.CWRU.Edu
andrewt@watnow.waterloo.edu (Andrew Thomas) (01/11/90)
In article <1990Jan10.191651.6471@usenet.ins.cwru.edu> chet@cwns1.CWRU.EDU (Chet Ramey) writes: In article andrewt@watnow.waterloo.edu (Andrew Thomas) writes: >It seems now that stuff in `` or $() >gets run in a subshell in 1.04 where there aren't really any jobs. Is >this fixable? It's fixed now; it was broken in 1.03. First of all, stuff in `` or $() [example of why 1.03 was broken] Chet Ramey But this doesn't really answer the question. Will it ever be possible for me to do exec $(jobs | fgprg 'emacs -nw') while still having the shell perform correctly in other cases? Would it require treating jobs separately from other builtins? -- Andrew Thomas andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo "If a million people do a stupid thing, it's still a stupid thing." - Opus
chet@cwns1.CWRU.EDU (Chet Ramey) (01/12/90)
In article <ANDREWT.90Jan10150653@watnow.waterloo.edu> andrewt@watnow.waterloo.edu (Andrew Thomas) writes: >But this doesn't really answer the question. Will it ever be possible >for me to do > exec $(jobs | fgprg 'emacs -nw') >while still having the shell perform correctly in other cases? Would >it require treating jobs separately from other builtins? OK, I'll try it again. No, I don't think it will ever be possible for you to do that, for two reasons: 1. Subshells don't have job control, so the `jobs' builtin returns nothing 2. Subshells don't have jobs, for the reasons I stated before, so `jobs' wouldn't return anything if job control was on. I think it would be too messy to make this work for just the `jobs' builtin, the way the code in execute_cmd.c is structured. It would require treating the `jobs' builtin separately from everything else. Chet Ramey -- Chet Ramey Network Services Group "Help! Help! I'm being Case Western Reserve University repressed!" chet@ins.CWRU.Edu
bfox@sbphy.ai.mit.edu (Brian Fox) (01/12/90)
Date: 8 Jan 90 14:11:38 GMT
From: utgpu!watserv1!watcgl!andrewt@jarvis.csri.toronto.edu (Andrew Thomas)
Organization: University of Waterloo, Waterloo, Ontario, Canada
Sender: bug-bash-request@prep.ai.mit.edu
I have a simple function:
function restart ()
{
eval `jobs | fgprg $1`
}
which used to work in bash 1.03. It seems now that stuff in `` or $()
gets run in a subshell in 1.04 where there aren't really any jobs. Is
this fixable?
Am I sadly out to lunch on this diagnosis? :-)
You are not out to lunch on this diagnosis. However, builtins that are
piped are run in a subshell, as are builtins that are explicitly run in
subshells, either with (jobs) or `jobs`. This means that they only have
access to the information that is present in subshells, which
unfortunately, doesn't include which jobs the parent is running. Maybe
this could be hacked in.
I think it is interesting to see what /bin/csh does with "jobs | more".
Brian