tcsh loses the foreground process group?

[Steve Watt]

On Wed, Dec 03, 2008 at 03:58:36PM -0800, Nate Eldredge wrote:
> On Tue, 2 Dec 2008, Steve Watt wrote:
> 
> >In <20081201042037.GA43208 at wattres.Watt.COM> Steve Watt wrote:

[ tcsh 6.15.00 ]

> >>The symptom is that when I do a long-ish running task inside a `` 
> >>expansion
> >>that I then ^C, nobody gets the foreground process group...  I never get
> >>a prompt back after the ^C, and ^T gets me
> >>
> >> load: 0.27 no foreground process group
> >
> >I've got another FreeBSD machine available that was running tcsh
> >6.14.00, and it does _NOT_ display the problem.  When I build
> >6.15.00 on that same box (/usr/src is more up to date than the
> >install right now), that does fail.
>
> Thanks for the report.  It looks like this is yet another manifestation of 
> a problem in tcsh, where it does inappropriate things in a vfork'ed 
> subshell.  In my tests, running tcsh with -F (which causes it to use fork 
> instead of vfork) causes the problem to go away.  It is also present in 
> 7.0-RELEASE and probably all later versions.

Did the behavior change between 6.14.00 and 6.15.00?  (Yeah, OK, I can
go look myself.)

OK, I went and looked.  Answer:  Yep, lots of additions of inappropriate
things in backeval().  But it no longer has a 10K limit.

> There are several open bugs related to this problem, but so far they do 
> not seem to have attracted the interest of any committers.  Among them 
> are:
> 
> bin/41297
> bin/52746
> bin/125185
> amd64/128259
> bin/129378 (which you just opened)
> 
> The fix is simple: make -F the default.  There is a minor performance 
> penalty, but that's a small price to pay for correct behavior.  A more 
> involved fix would be to make tcsh not do inappropriate things after vfork 
> (modifying global variables), or at least clean up before exiting, but 
> IMHO that is less clean; vfork really shouldn't be used here at all.

Actually, there's another cost to making -F default:  It makes hashstat
rather less useful.  OK, it's not like it's that useful to begin with,
and is arguably a debugging function, but it's a side effect.

As for a possible "why?" -F changes the hashstat behavior so?  Probably
because it's counting on not-quite-legal vfork() activity.

Ugh.  I'd managed to forget how unfun the code inside that shell is.  I'll
try to forget again.