* Re: idea for new feature (was: Re: sticky-note and zle bindings)
@ 2008-01-24 18:17 Robert Knight
2008-01-24 20:09 ` Richard Hartmann
2008-01-25 5:58 ` Bart Schaefer
0 siblings, 2 replies; 46+ messages in thread
From: Robert Knight @ 2008-01-24 18:17 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-24 18:17 idea for new feature (was: Re: sticky-note and zle bindings) Robert Knight
@ 2008-01-24 20:09 ` Richard Hartmann
2008-01-24 20:54 ` Richard Hartmann
2008-01-25 5:58 ` Bart Schaefer
1 sibling, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-24 20:09 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-24 20:09 ` Richard Hartmann
@ 2008-01-24 20:54 ` Richard Hartmann
2008-01-24 21:54 ` Robert Knight
0 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-24 20:54 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
If you are interested in the wishlist item in KDE's bug tracker:
http://bugs.kde.org/show_bug.cgi?id=156563
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-24 20:54 ` Richard Hartmann
@ 2008-01-24 21:54 ` Robert Knight
2008-01-24 23:22 ` Richard Hartmann
0 siblings, 1 reply; 46+ messages in thread
From: Robert Knight @ 2008-01-24 21:54 UTC (permalink / raw)
To: zsh-users
> 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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-24 21:54 ` Robert Knight
@ 2008-01-24 23:22 ` Richard Hartmann
[not found] ` <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com>
0 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-24 23:22 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-24 18:17 idea for new feature (was: Re: sticky-note and zle bindings) Robert Knight
2008-01-24 20:09 ` Richard Hartmann
@ 2008-01-25 5:58 ` Bart Schaefer
2008-01-25 9:49 ` Richard Hartmann
1 sibling, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-01-25 5:58 UTC (permalink / raw)
To: Robert Knight, zsh-users
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.)
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
[not found] ` <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com>
@ 2008-01-25 9:32 ` Richard Hartmann
2008-01-25 17:57 ` Bart Schaefer
2008-01-26 13:38 ` Fwd: idea for new feature (was: Re: sticky-note and zle bindings) Richard Hartmann
1 sibling, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-25 9:32 UTC (permalink / raw)
To: Robert Knight, zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 5:58 ` Bart Schaefer
@ 2008-01-25 9:49 ` Richard Hartmann
2008-01-25 20:10 ` Bastian, Waldo
0 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-25 9:49 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Robert Knight, zsh-users, bastian
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 9:32 ` Richard Hartmann
@ 2008-01-25 17:57 ` Bart Schaefer
2008-01-25 18:18 ` Robert Knight
2008-01-26 15:19 ` Richard Hartmann
0 siblings, 2 replies; 46+ messages in thread
From: Bart Schaefer @ 2008-01-25 17:57 UTC (permalink / raw)
To: Robert Knight, zsh-users
(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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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:19 ` Richard Hartmann
1 sibling, 1 reply; 46+ messages in thread
From: Robert Knight @ 2008-01-25 18:18 UTC (permalink / raw)
To: zsh-users
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.
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 9:49 ` Richard Hartmann
@ 2008-01-25 20:10 ` Bastian, Waldo
2008-01-26 15:29 ` Richard Hartmann
0 siblings, 1 reply; 46+ messages in thread
From: Bastian, Waldo @ 2008-01-25 20:10 UTC (permalink / raw)
To: Richard Hartmann, Bart Schaefer; +Cc: Robert Knight, zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 18:18 ` Robert Knight
@ 2008-01-26 2:12 ` Bart Schaefer
2008-01-26 15:41 ` Richard Hartmann
0 siblings, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-01-26 2:12 UTC (permalink / raw)
To: Robert Knight, zsh-users
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Fwd: idea for new feature (was: Re: sticky-note and zle bindings)
[not found] ` <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com>
2008-01-25 9:32 ` Richard Hartmann
@ 2008-01-26 13:38 ` Richard Hartmann
1 sibling, 0 replies; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 13:38 UTC (permalink / raw)
To: zsh-users
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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 17:57 ` Bart Schaefer
2008-01-25 18:18 ` Robert Knight
@ 2008-01-26 15:19 ` Richard Hartmann
2008-01-26 15:26 ` Clint Adams
1 sibling, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 15:19 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Robert Knight, zsh-users, bastian
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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
0 siblings, 2 replies; 46+ messages in thread
From: Clint Adams @ 2008-01-26 15:26 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Robert Knight, zsh-users, bastian
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-25 20:10 ` Bastian, Waldo
@ 2008-01-26 15:29 ` Richard Hartmann
0 siblings, 0 replies; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 15:29 UTC (permalink / raw)
To: Bastian, Waldo; +Cc: Bart Schaefer, Robert Knight, zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-26 2:12 ` Bart Schaefer
@ 2008-01-26 15:41 ` Richard Hartmann
2008-01-26 23:31 ` Bart Schaefer
0 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 15:41 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Robert Knight, zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-26 15:26 ` Clint Adams
@ 2008-01-26 15:42 ` Richard Hartmann
2008-01-26 15:43 ` Richard Hartmann
1 sibling, 0 replies; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 15:42 UTC (permalink / raw)
To: Richard Hartmann, Robert Knight, zsh-users, bastian
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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
1 sibling, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-26 15:43 UTC (permalink / raw)
To: Richard Hartmann, Robert Knight, zsh-users, bastian
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-26 15:41 ` Richard Hartmann
@ 2008-01-26 23:31 ` Bart Schaefer
2008-01-28 16:33 ` Andy Spiegl
0 siblings, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-01-26 23:31 UTC (permalink / raw)
To: zsh-users, Bastian, Waldo, Richard Hartmann; +Cc: Robert Knight, bastian
(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.
--
^ permalink raw reply [flat|nested] 46+ messages in thread
* OT: env vars passed by ssh [was Re: idea for new feature (was: Re: sticky-note and zle bindings)]
2008-01-26 15:43 ` Richard Hartmann
@ 2008-01-27 16:28 ` Clint Adams
0 siblings, 0 replies; 46+ messages in thread
From: Clint Adams @ 2008-01-27 16:28 UTC (permalink / raw)
To: Richard Hartmann; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-26 23:31 ` Bart Schaefer
@ 2008-01-28 16:33 ` Andy Spiegl
2008-06-07 4:39 ` Robert Knight
0 siblings, 1 reply; 46+ messages in thread
From: Andy Spiegl @ 2008-01-28 16:33 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-28 16:33 ` Andy Spiegl
@ 2008-06-07 4:39 ` Robert Knight
2008-06-10 4:13 ` Benjamin R. Haskell
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Robert Knight @ 2008-06-07 4:39 UTC (permalink / raw)
To: zsh-users
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.
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-07 4:39 ` Robert Knight
@ 2008-06-10 4:13 ` Benjamin R. Haskell
2008-06-11 0:02 ` Richard Hartmann
2008-06-10 23:57 ` Richard Hartmann
2008-06-20 12:06 ` Richard Hartmann
2 siblings, 1 reply; 46+ messages in thread
From: Benjamin R. Haskell @ 2008-06-10 4:13 UTC (permalink / raw)
To: Zsh Users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-07 4:39 ` Robert Knight
2008-06-10 4:13 ` Benjamin R. Haskell
@ 2008-06-10 23:57 ` Richard Hartmann
2008-06-20 12:06 ` Richard Hartmann
2 siblings, 0 replies; 46+ messages in thread
From: Richard Hartmann @ 2008-06-10 23:57 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-10 4:13 ` Benjamin R. Haskell
@ 2008-06-11 0:02 ` Richard Hartmann
2008-06-11 0:26 ` Benjamin R. Haskell
0 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-06-11 0:02 UTC (permalink / raw)
To: Benjamin R. Haskell; +Cc: Zsh Users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-11 0:02 ` Richard Hartmann
@ 2008-06-11 0:26 ` Benjamin R. Haskell
2008-06-11 1:17 ` Richard Hartmann
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Benjamin R. Haskell @ 2008-06-11 0:26 UTC (permalink / raw)
To: Zsh Users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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 11:47 ` Angel Olivera
2 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-06-11 1:17 UTC (permalink / raw)
To: Benjamin R. Haskell; +Cc: Zsh Users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-11 0:26 ` Benjamin R. Haskell
2008-06-11 1:17 ` Richard Hartmann
@ 2008-06-11 4:43 ` Bart Schaefer
2008-06-11 4:51 ` Benjamin R. Haskell
2008-06-11 11:47 ` Angel Olivera
2 siblings, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-06-11 4:43 UTC (permalink / raw)
To: Zsh Users
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [ZSH] Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-11 1:17 ` Richard Hartmann
@ 2008-06-11 4:48 ` Benjamin R. Haskell
0 siblings, 0 replies; 46+ messages in thread
From: Benjamin R. Haskell @ 2008-06-11 4:48 UTC (permalink / raw)
To: Zsh Users
[-- 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-11 4:43 ` Bart Schaefer
@ 2008-06-11 4:51 ` Benjamin R. Haskell
0 siblings, 0 replies; 46+ messages in thread
From: Benjamin R. Haskell @ 2008-06-11 4:51 UTC (permalink / raw)
To: Zsh Users
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".
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-11 0:26 ` Benjamin R. Haskell
2008-06-11 1:17 ` Richard Hartmann
2008-06-11 4:43 ` Bart Schaefer
@ 2008-06-11 11:47 ` Angel Olivera
2 siblings, 0 replies; 46+ messages in thread
From: Angel Olivera @ 2008-06-11 11:47 UTC (permalink / raw)
To: Zsh Users
[-- 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 --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-07 4:39 ` Robert Knight
2008-06-10 4:13 ` Benjamin R. Haskell
2008-06-10 23:57 ` Richard Hartmann
@ 2008-06-20 12:06 ` Richard Hartmann
2008-06-27 16:25 ` Richard Hartmann
2 siblings, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-06-20 12:06 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-06-20 12:06 ` Richard Hartmann
@ 2008-06-27 16:25 ` Richard Hartmann
0 siblings, 0 replies; 46+ messages in thread
From: Richard Hartmann @ 2008-06-27 16:25 UTC (permalink / raw)
To: Robert Knight; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-20 4:36 ` Matt Wozniski
@ 2008-01-20 9:09 ` Bart Schaefer
0 siblings, 0 replies; 46+ messages in thread
From: Bart Schaefer @ 2008-01-20 9:09 UTC (permalink / raw)
To: zsh-users
On Jan 19, 11:36pm, Matt Wozniski wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} > except "get_title".
}
} The long and short of it is so that a malicious text file, when cat'ed
} (or something similar), can't set the title to a command, request the
} title (this putting the title on the command line in the absense of a
} 'read'), and trick the user into pressing enter.
I see the argument, but I don't think that's the case here, because
"get_label" (icon label) works fine; "print $'\e]0;ookatme\a\e[20t'"
puts "Lookatme" at my PS1 prompt.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-20 0:01 ` Bart Schaefer
@ 2008-01-20 4:36 ` Matt Wozniski
2008-01-20 9:09 ` Bart Schaefer
0 siblings, 1 reply; 46+ messages in thread
From: Matt Wozniski @ 2008-01-20 4:36 UTC (permalink / raw)
To: zsh-users
On Jan 19, 2008 7:01 PM, Bart Schaefer wrote:
> It's possible to configure xterm to not respond to these sequences,
> and the window manager can suppress others.
>
> } Do you know from which version on it should be implemented?
>
> No, but another poster said it's been several years. I have what seems
> to be v.192 (based on RPM version string) and it responds to all of
> them except "get_title".
Getting the title via control sequence is often compiled out for
security reasons. See http://securityvulns.com/Edocument128.html ,
the "window title reporting" section. The long and short of it is so
that a malicious text file, when cat'ed (or something similar), can't
set the title to a command, request the title (this putting the title
on the command line in the absense of a 'read'), and trick the user
into pressing enter.
~Matt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-19 22:24 ` Andy Spiegl
@ 2008-01-20 0:01 ` Bart Schaefer
2008-01-20 4:36 ` Matt Wozniski
0 siblings, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-01-20 0:01 UTC (permalink / raw)
To: zsh-users
On Jan 19, 11:24pm, Andy Spiegl wrote:
}
} This sounds very useful. But my xterm (v.231 from debian/unstable)
} don't seem to understand theses control sequences yet.
It's possible to configure xterm to not respond to these sequences,
and the window manager can suppress others.
} Do you know from which version on it should be implemented?
No, but another poster said it's been several years. I have what seems
to be v.192 (based on RPM version string) and it responds to all of
them except "get_title".
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-19 21:46 ` Andy Spiegl
@ 2008-01-19 23:05 ` Bart Schaefer
0 siblings, 0 replies; 46+ messages in thread
From: Bart Schaefer @ 2008-01-19 23:05 UTC (permalink / raw)
To: zsh-users
On Jan 19, 10:46pm, Andy Spiegl wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} On 2008-01-18, 22:21, Richard Hartmann wrote:
} > SHELL_SESSION_COOKIE=`uuidgen`
}
} Could you elaborate on the retrieval part? How do newly opened (after a
} crash) shells know their cookie from before the crash?
That's the part that would require cooperation from the X session
manager and/or the terminal emulator.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-18 9:19 ` Bart Schaefer
@ 2008-01-19 22:24 ` Andy Spiegl
2008-01-20 0:01 ` Bart Schaefer
0 siblings, 1 reply; 46+ messages in thread
From: Andy Spiegl @ 2008-01-19 22:24 UTC (permalink / raw)
To: zsh-users
On 2008-01-18, 01:19, Bart Schaefer wrote:
> Here's something that may be of use. Recent xterm has adopted window
> control sequences from dtterm, according to
> http://www.xfree86.org/current/ctlseqs.html, so zsh might have a
> chance at saving/restoring some window state. I haven't tried Konsole
> but Gnome-terminal pays attention to a subset of this. Other
> terminals I don't know.
This sounds very useful. But my xterm (v.231 from debian/unstable) don't
seem to understand theses control sequences yet. Do you know from which
version on it should be implemented?
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.
Chau,
Andy.
--
Assumption is the mother of all screw-ups.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-18 21:21 ` Richard Hartmann
@ 2008-01-19 21:46 ` Andy Spiegl
2008-01-19 23:05 ` Bart Schaefer
0 siblings, 1 reply; 46+ messages in thread
From: Andy Spiegl @ 2008-01-19 21:46 UTC (permalink / raw)
To: zsh-users
On 2008-01-18, 22:21, Richard Hartmann wrote:
> It could be as easy as
>
> SHELL_SESSION_COOKIE=`uuidgen`
>
> with the magic cookie either generated or retrieved, whichever is applicable.
Could you elaborate on the retrieval part? How do newly opened (after a
crash) shells know their cookie from before the crash?
Chau,
Andy.
--
"I would be willing to bet that >99% of the people that use PGP wouldn't
recognize a backdoor in the code if it fell on them." -Tim Mooney
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 3:11 ` Bart Schaefer
2008-01-17 17:26 ` Andy Spiegl
@ 2008-01-18 21:21 ` Richard Hartmann
2008-01-19 21:46 ` Andy Spiegl
1 sibling, 1 reply; 46+ messages in thread
From: Richard Hartmann @ 2008-01-18 21:21 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
This is a re-send as I fail at replying to lists that do not munge
reply-to. Thanks to Bart for catching this.
On Jan 17, 2008 4:11 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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.
If we were to define a sane setup, I am certain many newer terminals would
love to comply with it. It could be as easy as
SHELL_SESSION_COOKIE=`uuidgen`
with the magic cookie either generated or retrieved, whichever is applicable.
This could even be used to keep histories from merging indiscriminately on
shutdown & restart. The 'local' history could be made to appear at the 'end'
of the history buffer. If you were to hack up extendedhistory to also include
said magic cookie, this could allow for some _really_ interesting stuff.
Once Bash catches up to ZSH, they could use the same variables and
setup.
Richard
PS: I am pretty certain Robert Knight would love to implement this for
Konsole within seconds :)
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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
1 sibling, 1 reply; 46+ messages in thread
From: Bart Schaefer @ 2008-01-18 9:19 UTC (permalink / raw)
To: zsh-users
On 1/17/08, Andy Spiegl <zsh.Andy@spiegl.de> wrote:
> > 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.
> Right, so let's start. :-)
Here's something that may be of use. Recent xterm has adopted window
control sequences from dtterm, according to
http://www.xfree86.org/current/ctlseqs.html, so zsh might have a
chance at saving/restoring some window state. I haven't tried Konsole
but Gnome-terminal pays attention to a subset of this. Other
terminals I don't know.
--- 8< --- snip --- 8< ---
#!/bin/zsh -f
# Implement two functions:
# xterm-tell control [args]
# xterm-ask control
# See xtermseq below for valid control names. -ask returns values in
$reply except for
# label and title which are returned in $REPLY.
# E.g. one way to maximize the window (see caveat below):
# xterm-ask screen_chars
# xterm-tell size_chars $reply
# Might there be terminfo names for these actions?
typeset -Ag xtermseq
xtermseq=(
1 deiconify 2 iconify
'3;X;Y' position
'4;H;W' size_pixels
5 raise 6 lower
7 refresh
'8;H;W' size_chars
'9;0' unmaximize '9;1' maximize
11 get_iconify
13 get_position
14 get_size_pixels
18 get_size_chars
19 get_screen_chars
20 get_label
21 get_title
)
local k
for k in ${(k)xtermseq}; do xtermseq[${xtermseq[$k]}]=$k; done
function xterm-tell {
local seq=${${${xtermseq[$1]:?no such command}/[HX]/$2}/[WY]/$3}
print -nr -- $'\e['${seq}t
}
function xterm-ask {
local esc
unset REPLY reply
1=get_${1#get_}
xterm-tell $1
case $1 in
(get_(label|title))
read -t 2 -rk 3 esc || return 1
read -rsd $'\e'
read -rk 1 esc
;;
(get_*)
read -t 2 -rk 2 esc || return 1
IFS=';' read -Arsd t
(( $#reply > 2 )) && shift reply
;;
esac
return 0
}
local documentation; read -rd $'\e' documentation <<'EOdoc' <<<$'\e'
CSI = "control sequence introducer": ESC [
OSC = "operating system command": ESC ]
ST = "string terminator": ESC backslash
Ps = "parameter string": (see list below)
All control sequences described here begin with CSI and end with "t".
Note that there are no spaces in control sequences or responses,
except possibly for the text responses for label and title; spaces
shown below are for readability.
Window manipulation (from dtterm, as well as extensions). These
controls may be disabled using the allowWindowOps resource. Valid
values for the first (and any additional parameters) are:
Ps = 1 -> De-iconify window.
Ps = 2 -> Iconify window.
Ps = 3 ; x ; y -> Move window to [x, y].
Ps = 4 ; height ; width -> Resize the xterm window in pixels.
Ps = 5 -> Raise the xterm window to the front of the stacking order.
Ps = 6 -> Lower the xterm window to the bottom of the stacking order.
Ps = 7 -> Refresh the xterm window.
Ps = 8 ; height ; width -> Resize the text area in characters.
Ps = 9 ; 0 -> Restore maximized window.
Ps = 9 ; 1 -> Maximize window (i.e., resize to screen size).
Ps = 1 1 -> Report xterm window state.
If the xterm window is open (non-iconified), returns CSI 1 t .
If the xterm window is iconified, returns CSI 2 t .
Ps = 1 3 -> Report xterm window position as CSI 3 ; x; yt
Ps = 1 4 -> Report xterm window in pixels as CSI 4 ; height ; width t
Ps = 1 8 -> Report size of text area as CSI 8 ; height ; width t
Ps = 1 9 -> Report size of screen in characters as CSI 9 ; height ; width t
Ps = 2 0 -> Report xterm window's icon label as OSC L label ST
Ps = 2 1 -> Report xterm window's title as OSC l title ST
Ps >= 2 4 -> Resize to Ps lines (DECSLPP)
The size of the screen in characters is often reported inaccurately.
Gnome-terminal as of v2.16 responds to 13/14/18/19 but fails to insert
the Ps digit 3/4/8/9 between the CSI and the reported dimensions, and
does not appear to respond to any of Ps in 1-9. Window managers may
also affect behavior; the Gnome desktop allows xterm to resize or
iconify itself but won't reliably let it reposition itself.
EOdoc
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 17:26 ` Andy Spiegl
@ 2008-01-18 2:12 ` Christopher Lord
2008-01-18 9:19 ` Bart Schaefer
1 sibling, 0 replies; 46+ messages in thread
From: Christopher Lord @ 2008-01-18 2:12 UTC (permalink / raw)
To: zsh-users
I do something like this using gnu screen. I have 12 windows (one for
each F-key). Screen starts each shell with an environment variable
$WINDOW. It's just an integer representing each window. I have my
history set up to write to ~/.zshist/history.$WINDOW. Then each window
writes the history to it's own history file.
I currently don't persist the $PWD into a file, but I imagine it is
pretty trivial to accomplish — just write $PWD to a file
~/.zshist/curdir.$WINDOW on precmd.
On Jan 17, 2008 12:26 PM, Andy Spiegl <zsh.Andy@spiegl.de> wrote:
> On 2008-01-16, 19:11, Bart Schaefer wrote:
> > Of course this is what share_history and inc_append_history are in
> > part intended to accomplish.
> Only for the command history, though.
> I was thinking about the directory stack.
>
> > 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?
> You're right - that's too complex and depends heavily on the user environment.
> But zsh could start the cooperation by providing the saved data and some kind
> of mechanism of reading it back in to restore the directory stack.
>
> Having that, it will be up to the users/terminal-guys/xserver-guys to use
> that data. When they know that zsh provides this they might be interested
> in using it.
>
> > 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.
> Right, so let's start. :-)
>
> > It's pretty simple to dump state somewhere from the precmd() function
> In a separate file for each zsh instance? Using the PID? Or a counter?
> Or maybe some unique identifier for each instance, say shell1, shell2, ...
> That way zsh could check at startup whether there is a state-file for
> its name and read it back in. The unique name should probably be in
> an environment variable. Hm, then in .xsession you would start several
> xterms with shells like that:
> ZSHNAME="shell-1" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-1"
> ZSHNAME="shell-2" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-2"
>
> How about that?
>
> Bye,
> Andy.
>
> --
> To err is human. To really screw it up takes a computer.
>
--
Christopher Lord
(w) www.clawbox.com
(e) christopherlord@gmail.com
(w) 1-905-413-3765
(m) 1-416-788-2564
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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-18 21:21 ` Richard Hartmann
1 sibling, 2 replies; 46+ messages in thread
From: Andy Spiegl @ 2008-01-17 17:26 UTC (permalink / raw)
To: zsh-users
On 2008-01-16, 19:11, Bart Schaefer wrote:
> Of course this is what share_history and inc_append_history are in
> part intended to accomplish.
Only for the command history, though.
I was thinking about the directory stack.
> 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?
You're right - that's too complex and depends heavily on the user environment.
But zsh could start the cooperation by providing the saved data and some kind
of mechanism of reading it back in to restore the directory stack.
Having that, it will be up to the users/terminal-guys/xserver-guys to use
that data. When they know that zsh provides this they might be interested
in using it.
> 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.
Right, so let's start. :-)
> It's pretty simple to dump state somewhere from the precmd() function
In a separate file for each zsh instance? Using the PID? Or a counter?
Or maybe some unique identifier for each instance, say shell1, shell2, ...
That way zsh could check at startup whether there is a state-file for
its name and read it back in. The unique name should probably be in
an environment variable. Hm, then in .xsession you would start several
xterms with shells like that:
ZSHNAME="shell-1" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-1"
ZSHNAME="shell-2" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-2"
How about that?
Bye,
Andy.
--
To err is human. To really screw it up takes a computer.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
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 21:21 ` Richard Hartmann
0 siblings, 2 replies; 46+ messages in thread
From: Bart Schaefer @ 2008-01-17 3:11 UTC (permalink / raw)
To: zsh-users
On Jan 16, 6:12pm, Andy Spiegl wrote:
}
} How about saving the current directory (or even the whole directory
} stack) of every zsh-instance so that it's possible to restore the
} status of all shells after an (in)voluntary crash, like network splits
} or an X-server crash.
Of course this is what share_history and inc_append_history are in
part intended to accomplish.
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.
One of my sysadmins back in grad school had a collection of csh scripts
read from his .login to do something like this, 20 years ago. I never
saw them in detail, but I got the impression that they were stashing
away data they'd extracted from the SunWindows environment on his old
Sun-1 desktop (before there was such a thing as a sparc chip or even
OpenWindows -- can you say "black-and-white bitmap"?). And he didn't
even have such a thing as precmd -- he was relying on aliases for "cd"
and the like.
^ permalink raw reply [flat|nested] 46+ messages in thread
* idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-16 15:59 ` Bart Schaefer
@ 2008-01-16 17:12 ` Andy Spiegl
2008-01-17 3:11 ` Bart Schaefer
0 siblings, 1 reply; 46+ messages in thread
From: Andy Spiegl @ 2008-01-16 17:12 UTC (permalink / raw)
To: zsh-users
Hi Bart,
> Wrapper widget.
Ok, thanks.
I just thought of another useful thingie using this technique:
How about saving the current directory (or even the whole directory stack) of
every zsh-instance so that it's possible to restore the status of all shells
after an (in)voluntary crash, like network splits or an X-server crash.
Of course the temporary data would have to be cleaned up when exiting the
shells normally. Something like the sessionstore.js of firefox.
Is that an imaginable feature?
Bye,
Andy.
--
Life is like a roll of toilet paper.
The closer it gets to the end, the faster it goes.
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2008-06-27 16:26 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-24 18:17 idea for new feature (was: Re: sticky-note and zle bindings) 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
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
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).