Re: signal handler within jed?

[Jörg Sommer <joerg@xxxxxxxxxxxx>]

Hallo John,

"John E. Davis" <davis@xxxxxxxxxxxxx> wrote:
> Jörg Sommer <joerg@xxxxxxxxxxxx> wrote:
>> But there's a bug:
>>
>> ioctl(2, TCGETS, 0xbff9c164)            = -1 EIO (Input/output error)
>> ioctl(2, TCSETSW, {B38400 opost isig icanon echo ...}) = -1 EIO (Input/output er
>> ror)
>> write(2, "***Fatal Error: Killed by signal "..., 37) = -1 EIO (Input/output erro
> [...]
>> Jed doesn't handle the SIGHUP correctly, i.e. it should not complain it
>> was killed by it.
>
> I would hesitate in calling this a bug.

But jed should not complain it was killed by SIGHUP. It's a common signal
and I would say this should not trigger a fatal error.

>> I would much more prefer jed refuses to quit if there are buffers with
>> unsaved data and don't having the autosave flag.
>
> If the terminal has been closed, then it would have to quit. 

XTerm sends SIGHUP before it quits. Try it in a shell:

% trap "echo I don't go" HUP

and try to close the window. Jed should take the SIGHUP as request to
quit and try to ask the user if he wants to save the unsaved data. If
stdin/stdout was closed due to the connection disappeared, jed should
behave as it currently does. But if it still can read from stdin and
write to stdout, it should behave as if exit_jed was called.

> Perhaps the window manager can be configured to not kill xterm when
> the user presses the "close" button.

My window manager (IceWM) doesn't kill the window. It send a signal to
XTerm and XTerm sends SIGHUP to process he has started, e.g. the shell.
This process passes the signal to its child processes, e.g. jed. This way
jed can block the closing of the window.

Bye, Jörg.
-- 
UNIX is user friendly, it's just picky about who its friends are

--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.