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

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

[Robert Knight]

Hi,

> It works with gnome-terminal, with konsole it doesn't.
> But konsole must have some kind of state management because
> my wife's KDE Desktop restores all shells including the PWD.

Konsole/KDE 3 reads the shell's current working directory from /proc
and saves that information.  When logging in again it opens each
window / tab with the same binary and with the working directory
recorded from /proc at shutdown.  This is a pretty poor solution since
information about the shell's variables (local and environment),
history, prompt etc. are not kept.

Please don't try to do window state setup from the shell.  There are a
number of reasons for this:

- gnome-terminal and Konsole both support tabs and a variety of other
window state features which cannot be controlled using escape codes
- KDE already has good built-in facilities for handling window state
between sessions, it can do a better job than zsh.  This includes
cases where windows are spread across multiple displays.
- Konsole supports additional properties for each terminal such as
color scheme, key binding, scrollback settings and font setup which
only it has access to.

In summary, the shell should remember information which it knows best
(prompt,variables,history etc.) and the terminal should keep the
information which it knows best.

I think the SHELL_SESSION_COOKIE suggestion (perhaps
SHELL_SESSION_ID?) would be best from my point of view as a Konsole
developer.  The value should be a unique ID of a known format so that
terminals don't end up generating pre-existing IDs by mistake.
The only problem with this approach is that there needs to be a way
for a particular session to be ended.  Some options:

* End a session when an explicit command is sent to it (eg. 'Ctrl+D' or 'exit')
* Don't end sessions.  Instead keep data around for the last X
sessions (where X might be 5,10 or 20).
* Define a new escape code to end a session.

Regards,
Robert.

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

[Richard Hartmann]

On Jan 24, 2008 7:17 PM, Robert Knight <robertknight@gmail.com> wrote:


> In summary, the shell should remember information which it knows best
> (prompt,variables,history etc.) and the terminal should keep the
> information which it knows best.

Fully agree. Or make the parts which modern terminals can handle
an extra option.


> * End a session when an explicit command is sent to it (eg. 'Ctrl+D' or 'exit')
> * Don't end sessions.  Instead keep data around for the last X
> sessions (where X might be 5,10 or 20).
> * Define a new escape code to end a session.

Probably offer all methods or an arbitary mix of them via options.
Personally, I would use option 1 for remote sessions and 2 for local
ones.


Richard

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

[Richard Hartmann]

If you are interested in the wishlist item in KDE's bug tracker:
http://bugs.kde.org/show_bug.cgi?id=156563

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

[Robert Knight]

> Probably offer all methods or an arbitary mix of them via options.

I'd really rather not.  Three ways of doing something means at least
three more things to test and three more places for bugs to sprout.

Regards,
Robert.

On 24/01/2008, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> If you are interested in the wishlist item in KDE's bug tracker:
> http://bugs.kde.org/show_bug.cgi?id=156563
>

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

[Richard Hartmann]

On Jan 24, 2008 10:54 PM, Robert Knight <robertknight@gmail.com> wrote:


> I'd really rather not.  Three ways of doing something means at least
> three more things to test and three more places for bugs to sprout.

Well, that part would be for the shell to implement, anyway. But as
most of the shells will not be terminated with ctrl-d/exit/logout there
must be an option to store everything on shutdown automagically.
Unless there is a reliable way to catch this, the shell would need
to keep persistant copies of all data at all times.


Richard

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

[Bart Schaefer]

On Jan 24,  6:17pm, Robert Knight wrote:
}
} I think the SHELL_SESSION_COOKIE suggestion (perhaps
} SHELL_SESSION_ID?) would be best from my point of view as a Konsole
} developer.  The value should be a unique ID of a known format so that
} terminals don't end up generating pre-existing IDs by mistake.

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?

} The only problem with this approach is that there needs to be a way
} for a particular session to be ended.

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?

} * End a session when an explicit command is sent to it
}   (eg. 'Ctrl+D' or 'exit')

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.

Of course I may be completely in left field here.

} * Don't end sessions.  Instead keep data around for the last X sessions
}   (where X might be 5,10 or 20).

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.

} * Define a new escape code to end a session.

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

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.)

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

[Richard Hartmann]

On Jan 25, 2008 3:57 AM, Robert Knight <robertknight@gmail.com> 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.

Oh, now I get it. Personally, I would prefer to keep X sessions around.
Explicitly deleting them could simply be a built-in command. Finding,
using and agreeing upon a control sequence seems like overkill, to me.

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 :)

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.


Richard

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

[Richard Hartmann]

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

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

[Bart Schaefer]

(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@gmail.com> 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.

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

[Robert Knight]

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@brasslantern.com> 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@gmail.com> 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.
>

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

[Bastian, Waldo]

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@lists.freedesktop.org to have your spec reviewed.

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

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

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

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

[Bart Schaefer]

On Jan 25,  6:18pm, Robert Knight wrote:
}
} > 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.

Well ... I can think of three cases.

(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.

(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.

(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).

What other case do you envision where the emulator can usefully be
involved?
 
} 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.

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.

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

[Richard Hartmann]

Forwarding for completeness as per Bart's implicit request :)


---------- Forwarded message ----------
From: Robert Knight <robertknight@gmail.com>
Date: Jan 25, 2008 3:57 AM
Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
To: Richard Hartmann <richih.mailinglist@gmail.com>


Hi,

> Well, that part would be for the shell to implement, anyway. But as
> most of the shells will not be terminated with ctrl-d/exit/logout there
> must be an option to store everything on shutdown automagically.

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.

Regards,
Robert.

On 24/01/2008, Richard Hartmann <richih.mailinglist@gmail.com> wrote:

> On Jan 24, 2008 10:54 PM, Robert Knight <robertknight@gmail.com> wrote:
>
>
> > I'd really rather not.  Three ways of doing something means at least
> > three more things to test and three more places for bugs to sprout.
>
> Well, that part would be for the shell to implement, anyway. But as
> most of the shells will not be terminated with ctrl-d/exit/logout there
> must be an option to store everything on shutdown automagically.
> Unless there is a reliable way to catch this, the shell would need
> to keep persistant copies of all data at all times.
>
>
> Richard
>

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

[Richard Hartmann]

On Jan 25, 2008 6:57 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:


> 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.

That is only true for local shells. Remote shells should offer a way
to resume. Speaking of which, is OpenSSH able to pass environment
variables from the local to the remote session?


> 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.

Even if there is no HUP and I cleanly exit a remote session, I would
probably want to restore session state, sometimes. A cheap way to
emulate screen, so to say.


> 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.

If the user can choose which set of conditions should have what effect
then yes, this would help quite a lot.


> It also implies that the shell needs a way to tell the GUI environment
> NOT to attempt, independently, to restore current directory, etc.

[XDG_]SHELL_SESSION_HANDLER or some such?
Could be 'shell', 'terminal', 'both' or a parseable list/an array?


> Scriptable.  Don't bother trying to define this in the shell itself.
[...]
> Again scriptable.

The shell should probably offer hooks and options for the script to use,
but yes, that is basically what I meant.


> See Util/reporter in the zsh source distribution for examples of how to
> dump out various shell state.

Will do, thanks :)


Richard

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

[Clint Adams]

On Sat, Jan 26, 2008 at 04:19:09PM +0100, Richard Hartmann wrote:
> That is only true for local shells. Remote shells should offer a way
> to resume. Speaking of which, is OpenSSH able to pass environment
> variables from the local to the remote session?

Yes, I pass LANG and LC_* when permitted.

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

[Richard Hartmann]

On Jan 25, 2008 9:10 PM, Bastian, Waldo <waldo.bastian@intel.com> wrote:


> 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.

Gladly, but that should probably wait a bit until we actually know what
should be done by which part. Does anyone else have any thoughts
about the relative merrits/disadvantages of enhancing XDG or don't
people care either way as long as there is a 'standardized' way to do
this?


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

Even though this looks kinda comical, wouldn't

  $XDG_DATA_HOME/$XDG_SESSION_SHELL_DIR/$XGD_SESSION_SHELL_ID

make more sense? I switched the position of SESSION and SHELL
on purpose, as this would faciliate future enhancement for session
state of other programs.


Richard

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

[Richard Hartmann]

On Jan 26, 2008 3:12 AM, Bart Schaefer <schaefer@brasslantern.com> 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

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

[Richard Hartmann]

On Jan 26, 2008 4:26 PM, Clint Adams <clint@zsh.org> wrote:


> Yes, I pass LANG and LC_* when permitted.

Perfect :)

Can you toss a snippet onto this list, please?


Richard

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

[Richard Hartmann]

On Jan 26, 2008 4:26 PM, Clint Adams <clint@zsh.org> wrote:


> Yes, I pass LANG and LC_* when permitted.

I forgot to ask what you meant by 'permitted'.


Richard

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

[Bart Schaefer]

(How many of the people Cc'd on this want to continue to be Cc'd?)

On Jan 26,  4:19pm, Richard Hartmann wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} On Jan 25, 2008 6:57 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Shells are slightly different beasts than other applications.  If I
} > explicitly exit from a shell, I'm done
} 
} That is only true for local shells. Remote shells should offer a way
} to resume.

There's certain state that the shell theoretically can save/restore,
independent of its display environment.  There's other state that
depends on interaction with the display environment.  In the case of
a remote shell, the display environment can only interact with the
shell to the extent that the remote connection protocol (e.g., ssh)
supports it, and it's highly unlikely that the local display manager
is going to be able (upon restart) to re-establish all the same
remote connections and start the correct remote applications.

The upshot of this, and of the three cases I outlined in my earlier
message, is that I think any further discussion of "remote" shells is
mostly just a diversion from the question of how the shell saves and
restores its state (and what state).  If you want to talk about how
Konsole should resolve what state to store in the event that it is
using a non-local display, discuss that elsewhere.

The most we should care about on this list is how the terminal (or
whatever starts up the shell, such as sshd) communicates to the shell
that a session is to be restored.

} Even if there is no HUP and I cleanly exit a remote session, I would
} probably want to restore session state, sometimes. A cheap way to
} emulate screen, so to say.
 
This is still not really related to whether the session is remote.  You
have some conditions under which you want the shell to keep its state.
If the shell can be scripted to detect those circumstances, you get
what you want.  There's no reason to give "remoteness" any special
consideration in this regard, except possibly to suggest that ssh[d]
treat shell session identity as part of X11 forwarding.

The idea that the local parent of ssh and the remote process that it
runs are somehow linked to the same session could be a useful one
even if (perhaps especially if) there is no X display involved.

} > It also implies that the shell needs a way to tell the GUI environment
} > NOT to attempt, independently, to restore current directory, etc.
} 
} [XDG_]SHELL_SESSION_HANDLER or some such?
} Could be 'shell', 'terminal', 'both' or a parseable list/an array?

I was thinking of a run-time communication (such as a control sequence
written to the psuedo-tty, though I don't really like that idea), but
I suppose it would be sufficient to tell the terminal in advance to
keep its fingers out of /proc/*/cwd.
 
On Jan 26,  4:29pm, Richard Hartmann wrote:
}
} Does anyone else have any thoughts about the relative
} merrits/disadvantages of enhancing XDG or don't people care either way
} as long as there is a 'standardized' way to do this?

I think that enough users run shells in situations completely divorced
from X desktops that it would be inappropriate to design a shell session
state mechanism with any direct dependence on, or reference to, XDG.

If XDG wants to incorporate such a shell session mechanism by reference,
that's up to them.

On Jan 26,  4:41pm, Richard Hartmann 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.

} If the shell is a child of ssh, there is no terminal to help the shell
} with garbage collection

ssh[d] would have to take on that role.  Something has to tell the shell
*when* to garbage-collect.  *What* gets collected is up to the shell.

-- 

OT: env vars passed by ssh [was Re: idea for new feature (was: Re: sticky-note and zle bindings)]

[Clint Adams]

On Sat, Jan 26, 2008 at 04:42:47PM +0100, Richard Hartmann wrote:
> Perfect :)
> 
> Can you toss a snippet onto this list, please?

On Sat, Jan 26, 2008 at 04:43:43PM +0100, Richard Hartmann wrote:
> I forgot to ask what you meant by 'permitted'.

You need

    SendEnv LANG LC_*

in your client-side ssh config, and

    AcceptEnv LANG LC_*

in the remote sshd_config.

This requires OpenSSH 3.9 or later.

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

[Andy Spiegl]

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.

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

[Robert Knight]

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.
>

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

[Benjamin R. Haskell]

On Sat, 7 Jun 2008, Robert Knight wrote:

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

I couldn't find the original thread (more than two months ago?), so I'm 
not sure what I'm suggesting below covers everything.


> [...]
>
> 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.

Have you tried 'screen'? I think it's a GNU project now (or maybe always 
was). It does basically what you're looking for. I use screen on most 
boxes I SSH to. And I run it on my own machine for long-running processes 
that I might want to come back to.

One of my startup files is even .zsh_screen:
[ "$TERM" = "screen" ] && other=Other || other=Running
S=$(screen -ls | perl -lnwe 'BEGIN{$sty=$ENV{STY}||"ZZZ";} print if /^\s/ and /\S/ and !/\b\Q$sty\E\b/')
[ -n "$S" ] && printf '%s screens:\n%s\n' $other $S

(basically munges the output of screen -ls to cut some lines and not show 
the current session)


On a machine where I have troubles (from some locations) with timeouts via 
SSH, I have it automatically start a screen session, and it tries to 
reattach if there's one that's doen.

On another, I have the command-line mercurial daemon and two command-line 
trac daemons running in screen sessions. If I SSH in and reattach, it's as 
if I never left.

Best,
Ben

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

[Richard Hartmann]

On Sat, Jun 7, 2008 at 06:39, Robert Knight <robertknight@gmail.com> wrote:


> 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.

I prefer a variable, as well.


[this used to be before the part above]
> but users might choose human-readable names if they wanted to do their
> own session management.

In that case, the shell would need to be able to handle changing
IDs. Think starting TE & shell with random ID, changing ID, switching over.


Richard

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

[Richard Hartmann]

On Tue, Jun 10, 2008 at 06:13, Benjamin R. Haskell <zsh@benizi.com> wrote:


> I couldn't find the original thread (more than two months ago?), so I'm not
> sure what I'm suggesting below covers everything.

It started on Jan 16th with an email by Andy Spiegl.


> Have you tried 'screen'?

Screen is somewhat similar, but tackles the problem on a different level.
This is something new which can act as an alternative, in some cases.


> On another, I have the command-line mercurial daemon and two
> command-line trac daemons running in screen sessions. If I SSH in
> and reattach, it's as if I never left.

Not quite true, as sometimes, when detached uncleanly, screen will
stop listening to STDOUT & STDERR of the programs that run within
it which makes some programs unhappy. irssi would be an example.
This takes us a tad too far from the topic at hand, though.


Richard

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

[Benjamin R. Haskell]

On Wed, 11 Jun 2008, Richard Hartmann wrote:

> On Tue, Jun 10, 2008 at 06:13, Benjamin R. Haskell <zsh@benizi.com> wrote:
>
>> I couldn't find the original thread (more than two months ago?), so I'm 
>> not sure what I'm suggesting below covers everything.
>
> It started on Jan 16th with an email by Andy Spiegl.
>

Thanks. I didn't even notice the bottom quote from your previous email 
until I just reread it, but "Jan 16th" got me there.


>> Have you tried 'screen'?
>
> Screen is somewhat similar, but tackles the problem on a different 
> level. This is something new which can act as an alternative, in some 
> cases.
>

I don't see the advantage or difference yet (except the "on a different 
level" part -- the 'screen' way makes more sense to me at this point).

Perusing the previous thread made me wonder: Is there a solution for the 
problem of needing co-operation from, say, the X Window manager? Or have 
you settled on being able to pass in a dead/killed shell's UUID/GUID?

(Is there an alternate interface to the online mailing list archive, btw? 
I hate all the clicking around -- I'd rather download an .mbox file and 
use it in Alpine.)


>> On another, I have the command-line mercurial daemon and two 
>> command-line trac daemons running in screen sessions. If I SSH in and 
>> reattach, it's as if I never left.
>
> Not quite true, as sometimes, when detached uncleanly, screen will stop 
> listening to STDOUT & STDERR of the programs that run within it which 
> makes some programs unhappy. irssi would be an example. This takes us a 
> tad too far from the topic at hand, though.
>

Huh. Never had that happen to me. Good to know.

But, won't this also be a problem with whatever mechanism you're 
envisioning? Or is this beyond the scope of what you'd want your "thing" 
to do (re-attaching already-running programs)?

Best,
Ben

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

[Richard Hartmann]

On Wed, Jun 11, 2008 at 02:26, Benjamin R. Haskell <zsh@benizi.com> wrote:


> I don't see the advantage or difference yet (except the "on a different
> level" part -- the 'screen' way makes more sense to me at this point).

For example, you can not space out screen windows over terminal
emulator tabs. Also, you can not run a screen session across a reboot
which works just fine with a ID thing.


> Perusing the previous thread made me wonder: Is there a solution for the
> problem of needing co-operation from, say, the X Window manager? Or have you
> settled on being able to pass in a dead/killed shell's UUID/GUID?

What would you neec X for? The TE sets the variable in the environment and
invokes the shell, which takes over from there.


> (Is there an alternate interface to the online mailing list archive, btw? I
> hate all the clicking around -- I'd rather download an .mbox file and use it
> in Alpine.)

I forwarded you the full thread. Is Alpine a proper replacement for pine, now?
I heard of pain when Alpine was born.


> But, won't this also be a problem with whatever mechanism you're
> envisioning? Or is this beyond the scope of what you'd want your "thing" to
> do (re-attaching already-running programs)?

Re-attaching is outside the scope of this. One could think about using a
mechanism like retty or simply stopping the execution of the 'child',
pivoting STDIN, STDOUT and STDERR from under its feet and letting
it run again, but that confuses a _lot_ of programs (for the obvious reason
that this is something you normally do not anticipate).


Richard

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

[Bart Schaefer]

On Jun 10,  8:26pm, Benjamin R. Haskell wrote:
}
} (Is there an alternate interface to the online mailing list archive, btw? 
} I hate all the clicking around -- I'd rather download an .mbox file and 
} use it in Alpine.)

If you go here ...

	http://www.zsh.org/mla/

The left of the 3-column table is "Every 100 articles tar'd & gzip'd."
The file names are numbers, which means if you unpack them in a new
directory they'll look like an MH folder, a format Alpine understands.
You may have to prefix the path name with "#mh" or something like that.

Or you can just do "alpine -f =(cat *)" to read them as an mbox.

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

[Benjamin R. Haskell]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4672 bytes --]

On Wed, 11 Jun 2008, Richard Hartmann wrote:

> On Wed, Jun 11, 2008 at 02:26, Benjamin R. Haskell <zsh@benizi.com> wrote:
>
>> I don't see the advantage or difference yet (except the "on a different 
>> level" part -- the 'screen' way makes more sense to me at this point).
>
> For example, you can not space out screen windows over terminal emulator 
> tabs. Also, you can not run a screen session across a reboot which works 
> just fine with a ID thing.

Both good points. I hadn't considered the former because terminals, tabs, 
and I don't get along (47 tabs in Firefox currently, but back when I was 
using Konsole, tabs just drove me mad.). And the latter because I'd been 
thinking in the 'screen' paradigm (just saving my running apps, not 
reinstantiating them or similar).


>> Perusing the previous thread made me wonder: Is there a solution for 
>> the problem of needing co-operation from, say, the X Window manager? Or 
>> have you settled on being able to pass in a dead/killed shell's 
>> UUID/GUID?
>
> What would you neec X for? The TE sets the variable in the environment 
> and invokes the shell, which takes over from there.

That question was regarding the issues in the second email in the thread 
you forwarded:

----------
From: Bart Schaefer <schaefer@brasslantern.com>
Date: Thu, Jan 17, 2008 at 05:11
To: zsh-users@sunsite.dk

[...]

The problem is that zsh can't do it by iself.  So, your X server has 
crashed and 20 shell windows went kablooie.  Even if every zsh has 
faithfully been recording its state somewhere, how does each new xterm you 
launch on the retarted X desktop know which one of the 20 saved states it 
should restore?

This is actually made *worse* by the fact that many modern X desktops have 
"session managers" that will remember the apps and placement of your 
windows and re-launch them on restart, so you may have 20 new xterms all 
examining the set of state files effectively at once.

Even supposing your session manager doesn't do this, and you have a 
command to launch a new xterm for every state file and somehow pass it 
(ZDOTDIR maybe?) the name of the file it should initialize, zsh can't 
track window placements or much of anything else that would help you to 
tell which window is which after they reappear.

The upshot is that this isn't a zsh feature -- it's a cooperative feature 
that requires effort from both the shell and whatever other user interface 
environment it's running inside.  It's pretty simple to dump state 
somewhere from the precmd() function, if only you know what to do with it 
later.

[...]
----------

And again in:

----------
From: Bart Schaefer <schaefer@brasslantern.com>
Date: Sun, Jan 20, 2008 at 01:05
To: zsh-users@sunsite.dk


On Jan 19, 10:46pm, Andy Spiegl wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
} >  SHELL_SESSION_COOKIE=`uuidgen`
That's the part that would require cooperation from the X session manager 
and/or the terminal emulator.
----------

But, later emails (that I didn't get to via the web interface) seem to 
scale that expectation back to the terminal emulator setting a variable or 
some other scheme (just storing 5,10,... sessions and automatically 
resuming unless told not to, etc.).


>> (Is there an alternate interface to the online mailing list archive, 
>> btw? I hate all the clicking around -- I'd rather download an .mbox 
>> file and use it in Alpine.)
>
> I forwarded you the full thread.

Thanks. Much easier.


> Is Alpine a proper replacement for pine, now? I heard of pain when 
> Alpine was born.

I've been using it for months now. But, I never had any trouble. Most of 
the issues on the lists (alpine-alpha formerly, and alpine-info 
currently[1]) seem to center around character-set issues (which I avoid by 
using UTF-8) and differences in pipe behavior (some GPG/PGP scripts can't 
get the old Pine piping behavior in Alpine).

[1] https://mailman1.u.washington.edu/mailman/listinfo/alpine-info


>> But, won't this also be a problem with whatever mechanism you're 
>> envisioning? Or is this beyond the scope of what you'd want your 
>> "thing" to do (re-attaching already-running programs)?
>
> Re-attaching is outside the scope of this. One could think about using a 
> mechanism like retty or simply stopping the execution of the 'child', 
> pivoting STDIN, STDOUT and STDERR from under its feet and letting it run 
> again, but that confuses a _lot_ of programs (for the obvious reason 
> that this is something you normally do not anticipate).
>

Yes, that makes more sense to me now with more context. (mainly: storing 
shell state rather than terminal state)

Best,
Ben

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

[Benjamin R. Haskell]

On Tue, 10 Jun 2008, Bart Schaefer wrote:

> On Jun 10,  8:26pm, Benjamin R. Haskell wrote:
> }
> } (Is there an alternate interface to the online mailing list archive, btw?
> } I hate all the clicking around -- I'd rather download an .mbox file and
> } use it in Alpine.)
>
> If you go here ...
>
> 	http://www.zsh.org/mla/
>
> The left of the 3-column table is "Every 100 articles tar'd & gzip'd." 
> The file names are numbers, which means if you unpack them in a new 
> directory they'll look like an MH folder, a format Alpine understands. 
> You may have to prefix the path name with "#mh" or something like that.
>
> Or you can just do "alpine -f =(cat *)" to read them as an mbox.
>

Thanks much. I think I misread that as "latest 100 articles" rather than 
"every".

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

[Angel Olivera]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Tue 10.Jun.08 20:26, Benjamin R. Haskell wrote:
> Perusing the previous thread made me wonder: Is there a solution for 
> the problem of needing co-operation from, say, the X Window manager? 
> Or have you settled on being able to pass in a dead/killed shell's 
> UUID/GUID?
>
> (Is there an alternate interface to the online mailing list archive, btw? 
> I hate all the clicking around -- I'd rather download an .mbox file and 
> use it in Alpine.)

If you like newsgruops, nntp://news.gmane.org has archives of many 
mailing lists (all of those that are on mail-archive.com). This one is 
at gmane.comp.shells.zsh.user.

-- 
redondos

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

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

[Richard Hartmann]

On Sat, Jun 7, 2008 at 06:39, Robert Knight <robertknight@gmail.com> wrote:

> 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.

> (2)  The terminal emulator specifies a file for the shell to save its
> state information
> to.

Did we reach any agreement on this? Robert, are you working on it? I
assume this will not make it into 4.1.0 ;)


Richard

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

[Richard Hartmann]

On Fri, Jun 20, 2008 at 14:06, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:

> Did we reach any agreement on this? Robert, are you working on it? I
> assume this will not make it into 4.1.0 ;)

Not wanting to annoy anyone, just reminding in case people forgot.
Feel free to cuss at me to shut up :)


Richard