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

["Robert Knight" <robertknight@xxxxxxxxx>]

Hi,

> Is what you mean that the shell needs to find out when it can "garbage
> collect" whatever data it has stored for a session that's never going
> to be resumed?

Yes.

> Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
> how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
> the path to it in the environment.

That would work when the shell is running locally, but what if the
shell is running on another system which the user is accessing via
ssh?  The terminal emulator doesn't have direct access to the remote
file system.

Since the shell is the program which is storing the data, I think it
makes sense for it to be responsible for deciding where to put it,
rather than the terminal.

> OTOH if my shell *windows* in a GUI environment are disconnected, or
> the shell is killed by HUP, I probably didn't intentionally exit and I'd
> like the state restored, to the extent possible, when the GUI resumes.

That is my thinking too.

Regards,
Robert.

On 25/01/2008, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> (I never saw the original message from Robert Knight and it's not in the
> list archives.)
>
> On Jan 25, 10:32am, Richard Hartmann wrote:
> } Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
> }
> } On Jan 25, 2008 3:57 AM, Robert Knight <robertknight@xxxxxxxxx> wrote:
> }
> } > There is a misunderstanding.  By "end the session", I meant ending a
> } > session and removing all data associated with it.  An analogy would be
> } > the option not to save the tabs in a web browser when closing it.
> } > Saving the session state would be the default behavior which would
> } > occur when logging out of the X session or closing the shell by
> } > sending SIGHUP for example.
>
> Shells are slightly different beasts than other applications.  If I
> explicitly exit from a shell, I'm done with whatever that shell was
> doing, and if I were to then start a new shell I wouldn't want it to
> return to the context of the the last shell I exited; the chances are
> very good that the new thing I'll be doing has nothing to do with
> the last thing.
>
> OTOH if my shell *windows* in a GUI environment are disconnected, or
> the shell is killed by HUP, I probably didn't intentionally exit and I'd
> like the state restored, to the extent possible, when the GUI resumes.
> That applies whether the GUI session is exited abnormally or when I
> choose "Log Out" from a menu.
>
> This implies that commands in the .zlogout or equivalent need to be
> able to determine what caused the shell to exit:  builtin command,
> user-generated EOF (ctrl-D), real EOF on stdin, HUP signal, etc.
>
> It also implies that the shell needs a way to tell the GUI environment
> NOT to attempt, independently, to restore current directory, etc.
>
> } One thing that would need to be decided is which sessions to delete
> } first. Oldest overall, oldest upate, smallest footprint, largest
> } footprint all have their respective merrits. Probably another option
>
> Scriptable.  Don't bother trying to define this in the shell itself.
>
> } Another thing to note is that some people would probably want to keep
> } the respective histories seperate, other would want to merge them on
> } session 'detach', still others would probably want to merge the
> } information on explicit session destruction.
> } Option one could be done by hand by the route of
> }   .zsh_history.$SHELL_SESSION_COOKIE
> } the others would probably, again, need options.
>
> Again scriptable.
>
> See Util/reporter in the zsh source distribution for examples of how to
> dump out various shell state.
>