ELM, job control and signals

[Alexis Rosen]

In article <4886 at dftsrv.gsfc.nasa.gov> jim at jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
>Well, I've never really used ELM with job control before but I tried it out to
>see if ELM would misbehave. When I did the ^Z ELM told me:
>Stopped: Use "fg" to return to ELM.
>
>ksh job control then responded with:
>[1] + Stopped (signal)        elm
>
>After about 5 minutes I brought elm back to the front... it said:
>Back in ELM. (you might need to explicitly request a redraw)
>
>Maybe:
>
>	1. You're running an older version
>	2. I didn't leave it in the back long enough
>	3. My version was compiled under 2.0... maybe something happened
>	   from 2.0 to 2.0.1 to change the way it compiles... I'll have to
>	   try that.

And the winner is... door number 2.

In fact, _most_ of the time job control works fine. Only after relatively
long periods of time away from ELM does it die with "Alarm Clock".

Richard Todd wrote in an earlier article that set42sig() would do the trick.
I thought of that the first time I hit this problem, and I'll probably try
it soon out of sheer frustration, but I don't think it will work. This is
because, in my experience, programs that can't deal with job control die
immediately on return to foreground, always. For example, rn wouldn't tolerate
job control until I patched it. ELM, however, explicitly recognizes and traps
^Z so it can print its little message before suspending.

Based on the message it prints and the fact the it only dies after lengthy
suspensions, I'm guessing that perhaps it's setting up some sort of signal
so that it doesn't get too stale? If so then the bug is in how fast it's
expiring, not that it's expiring at all. Any ideas?

---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis