Re: Odd job-reporting buglet (Re: Change in suspend behavior)

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On May 11, 10:47am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > schaefer[501] for i in bar foo; do cat & wait; done
} > [2] 27451
} > [2]  + suspended (tty input)  cat
} > [1] 27452
} > [1]  + suspended (tty input)  cat
} > zsh: suspended (tty input)  cat | 
} > zsh: running                for i in bar foo; do; cat & wait; done
} 
} The reason is pretty clear (to some): the sub-job returns and is
} stopped, so execpline() things it has to do all that super/sub-job
} handling it does when the sub-job was suspended with ^Z.

This happens only because of the `wait' command, right?  It does *not*
happen when I do `for i in bar foo; do; cat & sleep 5; done'.
 
} One way to try to fix this is to make execpline() check if the sub-job
} really was suspended because of a ^Z (SIGTSTP).

One can send TSTP with a `kill'.  Testing for TSTP has to be combined with
a test for whether the job is the foreground job at the time.

} The other way to try to fix this would be to check if the sub-job was
} ASYNC (i.e. it had a `&' at the end), pass that information up to (the
} right) execpline() and there decide to not wrap it into a super-job.

That sounds closer to the right thing to me, but wouldn't a test for "is
the foreground job" be equivalent (and possibly not need any more info
to be passed around)?

Or maybe it would be possible to know that we're in a `wait' command and
simply not do any of this processing?  But that would be equivalent to
"is this the foreground job" as well (as the `wait' would be the fore-
ground job in that case, not the job that got the signal).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net