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

["Robert Knight" <robertknight@gmail.com>]

Hi folks,

I'd like to implement my part of this quite soon.  So here is a more
concrete proposal:

(1)  The terminal emulator creates a unique alphanumeric ID string for each
new session and passes it to the shell as an environment variable
$SHELL_SESSION_ID.
When the shell is killed via a SIGHUP it saves that state and the
associated session ID.
When restoring that session, the terminal emulator starts a new
instance of the shell as
usual, with the previously used $SHELL_SESSION_ID value.  The shell
looks for state saved
under that name and restores the previous state.  If no state is saved
against the id then
the shell can assume that it is a new session.  The ID would be
alphanumeric, with no fixed
length or format.  I would probably use Qt's UUID generator to come up
with something suitable
but users might choose human-readable names if they wanted to do their
own session management.

(2)  The terminal emulator specifies a file for the shell to save its
state information
to.  If the file is empty or does not exist then the shell assumes
this is a new session.  Otherwise it restores the contents of the
file.  The save/restore handling then works as in (1).

I favour the first option because the shell can pick a suitable place
to store its
state information which is in the same location/format as the rest of
its data.  Unlike a filename, an ID also works over remote
connections.

Policies over exactly what gets saved and restored and how long that
information should be kept for would be left up to the shell to begin
with.
I can make suggestions about what would be most useful however,
roughly in priority order.
The real gist is to minimize the time spent doing repetetive setup
routines to prepare for
working on various tasks.

- Environment variables (probably not the complete environment but
rather a delta between
the environment inherited by the shell when it started and the
environment in the shell when
it was closed)
- Prompt
- Aliases
- Functions

Digging back through my mail from users, something which would earn
much love from sysadmins
would be if they could save the state of their terminal, with 10-20
connections to various
machines via SSH and later restore that again instantly - including as
much state as possible
on the remote end.

Regards,
Robert.

2008/1/28 Andy Spiegl <zsh.Andy@spiegl.de>:
> On 2008-01-26, 15:31, Bart Schaefer 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.
>
> I really like the idea of restoring the program that was running
> before the "crash", but I'd suggest not to reexecute it (which may
> have fatal side effects) but just putting it on the command line.
> The user can then decide whether to press enter or not.
>
> Chau,
>  Andy.
>
> --
>  Once you've seen one shopping center you've seen a mall.
>