Re: idea for new feature (was: Re: sticky-note and zle bindings)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

(How many of the people Cc'd on this want to continue to be Cc'd?)

On Jan 26,  4:19pm, Richard Hartmann wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} On Jan 25, 2008 6:57 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > Shells are slightly different beasts than other applications.  If I
} > explicitly exit from a shell, I'm done
} 
} That is only true for local shells. Remote shells should offer a way
} to resume.

There's certain state that the shell theoretically can save/restore,
independent of its display environment.  There's other state that
depends on interaction with the display environment.  In the case of
a remote shell, the display environment can only interact with the
shell to the extent that the remote connection protocol (e.g., ssh)
supports it, and it's highly unlikely that the local display manager
is going to be able (upon restart) to re-establish all the same
remote connections and start the correct remote applications.

The upshot of this, and of the three cases I outlined in my earlier
message, is that I think any further discussion of "remote" shells is
mostly just a diversion from the question of how the shell saves and
restores its state (and what state).  If you want to talk about how
Konsole should resolve what state to store in the event that it is
using a non-local display, discuss that elsewhere.

The most we should care about on this list is how the terminal (or
whatever starts up the shell, such as sshd) communicates to the shell
that a session is to be restored.

} Even if there is no HUP and I cleanly exit a remote session, I would
} probably want to restore session state, sometimes. A cheap way to
} emulate screen, so to say.
 
This is still not really related to whether the session is remote.  You
have some conditions under which you want the shell to keep its state.
If the shell can be scripted to detect those circumstances, you get
what you want.  There's no reason to give "remoteness" any special
consideration in this regard, except possibly to suggest that ssh[d]
treat shell session identity as part of X11 forwarding.

The idea that the local parent of ssh and the remote process that it
runs are somehow linked to the same session could be a useful one
even if (perhaps especially if) there is no X display involved.

} > It also implies that the shell needs a way to tell the GUI environment
} > NOT to attempt, independently, to restore current directory, etc.
} 
} [XDG_]SHELL_SESSION_HANDLER or some such?
} Could be 'shell', 'terminal', 'both' or a parseable list/an array?

I was thinking of a run-time communication (such as a control sequence
written to the psuedo-tty, though I don't really like that idea), but
I suppose it would be sufficient to tell the terminal in advance to
keep its fingers out of /proc/*/cwd.
 
On Jan 26,  4:29pm, Richard Hartmann wrote:
}
} Does anyone else have any thoughts about the relative
} merrits/disadvantages of enhancing XDG or don't people care either way
} as long as there is a 'standardized' way to do this?

I think that enough users run shells in situations completely divorced
from X desktops that it would be inappropriate to design a shell session
state mechanism with any direct dependence on, or reference to, XDG.

If XDG wants to incorporate such a shell session mechanism by reference,
that's up to them.

On Jan 26,  4:41pm, Richard Hartmann wrote:
} 
} Restoring the programs that ran is a very interesting idea. I like it :)

Not "the programs that ran".  The programs that *were running*; that is,
something the shell had to SIGHUP when it exited.  I'd be very leery of
automatically restarting anything other than the foreground job, though,
and maybe not even that if it was a pipeline.

} If the shell is a child of ssh, there is no terminal to help the shell
} with garbage collection

ssh[d] would have to take on that role.  Something has to tell the shell
*when* to garbage-collect.  *What* gets collected is up to the shell.

--