From: "Richard Hartmann" <richih.mailinglist@gmail.com>
To: "Bart Schaefer" <schaefer@brasslantern.com>
Cc: "Robert Knight" <robertknight@gmail.com>,
zsh-users@sunsite.dk, bastian@kde.org
Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
Date: Fri, 25 Jan 2008 10:49:46 +0100 [thread overview]
Message-ID: <2d460de70801250149t360f9938u18d458b03f464c72@mail.gmail.com> (raw)
In-Reply-To: <080124215848.ZM19758@torch.brasslantern.com>
On Jan 25, 2008 6:58 AM, Bart Schaefer <schaefer@brasslantern.com> 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
next prev parent reply other threads:[~2008-01-25 9:50 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-24 18:17 Robert Knight
2008-01-24 20:09 ` Richard Hartmann
2008-01-24 20:54 ` Richard Hartmann
2008-01-24 21:54 ` Robert Knight
2008-01-24 23:22 ` Richard Hartmann
[not found] ` <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com>
2008-01-25 9:32 ` Richard Hartmann
2008-01-25 17:57 ` Bart Schaefer
2008-01-25 18:18 ` Robert Knight
2008-01-26 2:12 ` Bart Schaefer
2008-01-26 15:41 ` Richard Hartmann
2008-01-26 23:31 ` Bart Schaefer
2008-01-28 16:33 ` Andy Spiegl
2008-06-07 4:39 ` Robert Knight
2008-06-10 4:13 ` Benjamin R. Haskell
2008-06-11 0:02 ` Richard Hartmann
2008-06-11 0:26 ` Benjamin R. Haskell
2008-06-11 1:17 ` Richard Hartmann
2008-06-11 4:48 ` [ZSH] " Benjamin R. Haskell
2008-06-11 4:43 ` Bart Schaefer
2008-06-11 4:51 ` Benjamin R. Haskell
2008-06-11 11:47 ` Angel Olivera
2008-06-10 23:57 ` Richard Hartmann
2008-06-20 12:06 ` Richard Hartmann
2008-06-27 16:25 ` Richard Hartmann
2008-01-26 15:19 ` Richard Hartmann
2008-01-26 15:26 ` Clint Adams
2008-01-26 15:42 ` Richard Hartmann
2008-01-26 15:43 ` Richard Hartmann
2008-01-27 16:28 ` OT: env vars passed by ssh [was Re: idea for new feature (was: Re: sticky-note and zle bindings)] Clint Adams
2008-01-26 13:38 ` Fwd: idea for new feature (was: Re: sticky-note and zle bindings) Richard Hartmann
2008-01-25 5:58 ` Bart Schaefer
2008-01-25 9:49 ` Richard Hartmann [this message]
2008-01-25 20:10 ` Bastian, Waldo
2008-01-26 15:29 ` Richard Hartmann
-- strict thread matches above, loose matches on Subject: below --
2008-01-04 10:59 Fw: Zsh - push current command on history without executing it Peter Stephenson
2008-01-04 11:04 ` Mikael Magnusson
2008-01-04 11:24 ` Casper Gripenberg
2008-01-09 18:58 ` zzapper
2008-01-13 8:00 ` Bart Schaefer
2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl
2008-01-16 15:59 ` Bart Schaefer
2008-01-16 17:12 ` idea for new feature (was: Re: sticky-note and zle bindings) Andy Spiegl
2008-01-17 3:11 ` Bart Schaefer
2008-01-17 17:26 ` Andy Spiegl
2008-01-18 2:12 ` Christopher Lord
2008-01-18 9:19 ` Bart Schaefer
2008-01-19 22:24 ` Andy Spiegl
2008-01-20 0:01 ` Bart Schaefer
2008-01-20 4:36 ` Matt Wozniski
2008-01-20 9:09 ` Bart Schaefer
2008-01-18 21:21 ` Richard Hartmann
2008-01-19 21:46 ` Andy Spiegl
2008-01-19 23:05 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d460de70801250149t360f9938u18d458b03f464c72@mail.gmail.com \
--to=richih.mailinglist@gmail.com \
--cc=bastian@kde.org \
--cc=robertknight@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-users@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).