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

["Richard Hartmann" <richih.mailinglist@xxxxxxxxx>]

On Jan 26, 2008 3:12 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:


> (1) The emulator itself is running remotely and displaying on the local
> desktop.  In this case the emulator *does* have access to the "remote"
> filesystem, but the desktop manager can't restore such a window, so
> there's nothing (special) for us to do.

Terminals could keep a session state for themselves, so if I ran

  konsole --restore-session foo

it could restore everything, no matter if it is local and under the
desktop manager's control or not. This might even make the overall
terminal session handling cleaner.


> (2) The emulator is local but the application is "ssh".  This is out of
> our purview; ssh could propagate the SHELL_SESSION_* environment and it
> would be up to sshd to do the right thing on the remote end as part of
> its X11 protocol forwarding or whatever, but whether it does is not for
> us to determine.

Well, as soon as the shell see the appropriate variables, it can just do
whatever it was set up to do in that case, so this case should be transparent.


> (3) The emulator is local and the shell is local, but within that shell
> the user has started up "ssh" to somewhere.  Our responsibility ends
> with making sure that the local shell can record its state, which may
> include that it needs to start up an ssh process.  Beyond that point we
> are back to case (2).

Yes.


Restoring the programs that ran is a very interesting idea. I like it :)


> What other case do you envision where the emulator can usefully be
> involved?

Atm, none.


> The shell DOES determine where to store the data.  The emulator (or the
> desktop session) is just creating a semaphore file; think of it the same
> way you'd think of .pid file in /var/run, except there's one for each
> shell session.  Whether the shell uses it to stash data is secondary,
> and up to the shell save-state implementation; I just threw that part
> out as a suggestion because it avoids the shell itself needing to have
> garbage-session collection code.

If the shell is a child of ssh, there is no terminal to help the shell with
garbage collection, should it must be able to do this by itself, anyway.
Of course, the HANDLER variable could be used to determine who
should actually do the collection if both the terminal and the shell offer
this.


Richard