🚀 go-pugleaf

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			

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

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			

   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