Idle Users

[Fairlight]

At Thu, Jun 17, 2004 at 05:11:42PM -0700 or thereabouts, 
suspect Bob Rasmussen was observed uttering:
> 
> Because lots of function keys are needed by many users, we never even
> consider Alt-F4 as synonymous with Quit. We capture it, and allow the user
> to attach a keymap to it.

Gotcha.  I thought it was a binding but had never tested in my own coding.
I thought I'd run into something that captured it though.  I guess it's a
WM default if the app doesn't re-bind, then.

> You misunderstand. It's not that telnetd or sshd would trap the HUP. They
> pass it along or even generate it in the case where the connection goes
> down. The problem is when some shell script in the process tree has
> trapped the HUP, or when the runtime ignores it (not the case with fP).

Understood.

If someone is trapping HUP, I'm of the school of thought that says they
live with the consequences of their actions.  I've trapped it before, but
never in a context that would be harmful.  Just long enough to gracefully
finish an atomic logical operation and then exit.

I really don't think planning for that far down the chain is the job of the
emulator or its developers.  That's a case of the server-side environment,
IMHO.  So long as the client-side is graceful and does things properly, I
think it's up to the server admins/users to configure their environment and
applications properly.

> Thanks for your comments on 'screen', too.

My pleasure.  It's really invaluable.  I've used it since before it ever
got switched to the FSF.  It used to be hosted at orst.edu.  :)  It was
great for those wonderfully...uhm, stable (*cough*) 1200/2400 baud modem
connections we had back in the day.  Saved many a headache and much code
loss.

One additional note to that is that you might also check out 'multiuser on'
and the access control functionality in screen.  I've used it (today, even)
to bring people in and let them attach to my session concurrently for
training, collaboration, or just demonstration.  And you can nicely set it
so that a list of users can access your sessions, but they can have only
certain access to certain multiplexes.

Assume I have screen multiplexed with three "windows" (for lack of a
better word).  One is 'fairlite' local to my linux box, one is my shell
account, and one is root on my linux box.  I can force it so that 'bob'
can read/write to the first, read-only on the second, and not even get
at the root one at all.  It's pretty robust.  About my only complaint is
that -both- sides must (apparently) trigger the screen-switching bindings.
If I'm on and someone attaches, they don't necessarily start on the same
screen I'm currently on, and when I switch, they also have to switch.  It
can be used independantly by multiple parties, and logging off the main
session doesn't nuke the other users off of that session as it would in
DoubleVision--that's the upside.  But in a training situation, if you
deal with multiple windows, I wish there was a way to force the switch to
all connected users -from- the user who owns the session.  It's a bit of a
trade-off.  However, besides offering what you wanted, it pretty much acts
like a DoubleVision or ttysnoop substitute.

Hey Jay, if you're reading--I've been over the man page like 30 times.  Is
there actually a way to do what I want with it with the binding in
multiuser mode?  Something I've missed?  *hopeful look*

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html