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

["Bastian, Waldo" <waldo.bastian@xxxxxxxxx>]

Replying to the XDG part: You are encouraged to write up a small spec
that defines file formats & file locations for this. The file locations
should then be defined in terms of $XDG_DATA_HOME and reference the
base-dir spec.

For example, you can say that a shell should look for a file named
$XDG_DATA_HOME/shell_sessions/$SHELL_SESSION_ID 

Please post to xdg@xxxxxxxxxxxxxxxxxxxxx to have your spec reviewed.

Cheers,
Waldo
 
Intel Corporation - Platform Software Engineering, UMG - Hillsboro,
Oregon

-----Original Message-----
From: Richard Hartmann [mailto:richih.mailinglist@xxxxxxxxx] 
Sent: Friday, January 25, 2008 1:50 AM
To: Bart Schaefer
Cc: Robert Knight; zsh-users@xxxxxxxxxx; bastian@xxxxxxx
Subject: Re: idea for new feature (was: Re: sticky-note and zle
bindings)

On Jan 25, 2008 6:58 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
wrote:


> So in this scheme the terminal emulator creates the SHELL_SESSION_ID
> and places it in the environment when the shell is started?  I.e.,
> Konsole would be responsible for telling the shell which session to
> resume (or to start a new one)?
>
> If that's not what you mean, can you be more specific?

That is exactly what I meant, yes. If ZSH already has information
regarding
this ID, it can use it. If it does not, it would create a new set of
whatever it
needs to keep all info.


> I'm not sure I follow the nuances here.  If a single window closes
> before the user shuts his whole desktop session down, then the session
> for that window ends, doesn't it?  Regardless of what application is
> the creator of that window?
>
> 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, the garbage collection is the issue, here.


> Certainly the shell can clean up when it believes the session is not
> going to be resumed.  Even if a terminal emulator later re-uses the
> same session ID, the shell will just act as if a new session started.

Unless the shell is told explicitly by some mechanism that its session
is ending now, I do not think a shell should ever remove stuff from its
own session. Unless the session state's size goes over a certain
threshold, that is. That way, newer instances of the shell could
determine if a certain session state collection can be destroyed.

Another thing to keep in mind is that a way to tell, from the outside,
if a session state collection is currently in use would be needed.


> You'd have to do some kind of time limit rather than a number limit.
> I sometimes have more than 20 shell windows open at a time.

It would probably be best to let the user decide what garbage collection
method[s] he or she prefers. ZSH is famous for its fine-grained control
over pretty much everything, there is a reputation to uphold :p


> What does "escape code" mean here?  What sends it, and to who?

I assume Robert meant a terminal would tell the shell it is OK to
collect,
now.


> 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.  The shell can then choose to put
> its session data in that file, or put it somewhere else and use the
> file as a semaphore.  If the emulator (or the desktop session, even)
> decides that the shell session has ended, it removes that file.  If
> the shell stored its data in the file, the session is gone.  If it
> used the file as a semaphore it can garbage-collect any session data
> for which the file no longer exists.  (The file would have to be in a
> predictable location (SHELL_SESSION_DIR ?) for the latter to work.)

That idea is also quite neat. Perhaps a DIR and an ID? If all shells
were
to always use the ID in every file related to a specific session, it
could
keep an arbitary set of files with arbitary names, probably even
subdirectories, and the terminal would still know what to delete if it
chose
to do so.


The more I think about this, the more I suspect this could be tied into
the
XDG [1] specs. It follows a somwhat similar goal and one mechanism
could push the adoption of the other as the exposure of both would
increase. On a hunch, I am CC'ing Waldo Bastian, who seems to be
the main author of XDG.


Richard

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html