* Fw: Zsh - push current command on history without executing it @ 2008-01-04 10:59 Peter Stephenson 2008-01-04 11:04 ` Mikael Magnusson 0 siblings, 1 reply; 51+ messages in thread From: Peter Stephenson @ 2008-01-04 10:59 UTC (permalink / raw) To: Zsh Users Forwarded from someone presumably not on the list. Begin forwarded message: Date: Mon, 24 Dec 2007 03:59:55 +0200 From: Casper Gripenberg <casper.gripenberg@kotiportti.fi> To: pws@zsh.org Subject: Zsh - push current command on history without executing it Hi..I was reading the zsh manual and trying to figure out how to push the current command line into the history list wihout actually executing the command. push-line does almost what I want, but it pops the command back into view after I issue the next command. What I'm looking for is something like push-history.. but I can't find it. Is there such a thing or any way to make zsh do something like that? Thanks. Casper ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it 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 0 siblings, 1 reply; 51+ messages in thread From: Mikael Magnusson @ 2008-01-04 11:04 UTC (permalink / raw) To: casper.gripenberg; +Cc: Zsh Users ---------- Forwarded message ---------- From: Chris Johnson <cjohnson@cs.utk.edu> Date: 20 Dec 2007 19:26 Subject: Re: command-cancellation with # To: Micah Elliott <mde@micahelliott.com>, zsh-users@sunsite.dk Micah Elliott sent me the following 1.3K: > On 2007-12-20 Mikael Magnusson wrote: > > > On 20/12/2007, Micah Elliott <mde@micahelliott.com> wrote: > > > $ #ls foo > > > zsh: bad pattern: #ls > > > > > > Is there a way to make this work in zsh the way it does in bash? > > > > setopt interactivecomments > > Great, that works. Thanks! > > Is there some way I could have discovered that? I don't see it > in zshall(1). I do see that it (and a few others) are set now by > running 'setopt', but it would be nice to know what all the > available options are (which aren't in the manpage). It's in my zshall, and more narrowly, in zshoptions. For the functionality of "pausing" a command line, you can also bind the push-line widget (check out the zshzle man page for key binding and line-editing options) to temporarily interrupt a command so as to execute another, and have the interrupted command return for editing automatically. I bind this to Alt-Q (or Escape-Q): bindkey "^[Q" push-line And I have this custom widget to help me store a command line in history without executing it: commit-to-history() { print -s ${(z)BUFFER} zle send-break } zle -N commit-to-history bindkey "^X^H" commit-to-history So, I type a command, hit Ctrl-X Ctrl-H, and then retrieve my command from history when I need it. -- Chris Johnson cjohnson@cs.utk.edu http://www.cs.utk.edu/~cjohnson On 04/01/2008, Peter Stephenson <pws@csr.com> wrote: > Forwarded from someone presumably not on the list. > > > Begin forwarded message: > > Date: Mon, 24 Dec 2007 03:59:55 +0200 > From: Casper Gripenberg <casper.gripenberg@kotiportti.fi> > To: pws@zsh.org > Subject: Zsh - push current command on history without executing it > > > > Hi..I was reading the zsh manual and trying to > figure out how to push the current command line > into the history list wihout actually executing > the command. > > push-line does almost what I want, but it pops > the command back into view after I issue the next > command. What I'm looking for is something like > push-history.. but I can't find it. Is there > such a thing or any way to make zsh do something > like that? > > Thanks. > > Casper > -- Mikael Magnusson ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it 2008-01-04 11:04 ` Mikael Magnusson @ 2008-01-04 11:24 ` Casper Gripenberg 2008-01-09 18:58 ` zzapper 0 siblings, 1 reply; 51+ messages in thread From: Casper Gripenberg @ 2008-01-04 11:24 UTC (permalink / raw) To: Zsh Users Mikael Magnusson wrote: > [...] > And I have this custom widget to help me store a command line in history > without executing it: > > commit-to-history() { > print -s ${(z)BUFFER} > zle send-break > } > zle -N commit-to-history > bindkey "^X^H" commit-to-history > > So, I type a command, hit Ctrl-X Ctrl-H, and then retrieve my command > from history when I need it. That's perfect. Thanks. Casper ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it 2008-01-04 11:24 ` Casper Gripenberg @ 2008-01-09 18:58 ` zzapper 2008-01-09 19:15 ` Paul Lew 2008-01-13 8:00 ` Bart Schaefer 0 siblings, 2 replies; 51+ messages in thread From: zzapper @ 2008-01-09 18:58 UTC (permalink / raw) To: zsh-users Casper Gripenberg wrote in news:477E177A.3060303@kotiportti.fi: > Mikael Magnusson wrote: > > [...] >> And I have this custom widget to help me store a command line in history >> without executing it: >> >> commit-to-history() { >> print -s ${(z)BUFFER} >> zle send-break >> } >> zle -N commit-to-history >> bindkey "^X^H" commit-to-history >> Good one, BTW you can use this as a temporary memory for a telephone number etc etc as well etc. I seem to have trouble with double letter bindkeys , or is this the old vi- edit mode problem? -- zzapper http://www.rayninfo.co.uk/vimtips.html http://rayninfo.co.uk/tips/zshtips.html ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it 2008-01-09 18:58 ` zzapper @ 2008-01-09 19:15 ` Paul Lew 2008-01-13 8:00 ` Bart Schaefer 1 sibling, 0 replies; 51+ messages in thread From: Paul Lew @ 2008-01-09 19:15 UTC (permalink / raw) To: zzapper; +Cc: zsh-users >>>>> "zzapper" == zzapper <david@tvis.co.uk> writes: zzapper> Casper Gripenberg wrote in news:477E177A.3060303@kotiportti.fi: >> Mikael Magnusson wrote: >> > [...] >>> And I have this custom widget to help me store a command line >>> in history without executing it: >>> >>> commit-to-history() { >>> print -s ${(z)BUFFER} >>> zle send-break >>> } >>> zle -N commit-to-history >>> bindkey "^X^H" commit-to-history >>> zzapper> Good one, BTW you can use this as a temporary memory for zzapper> a telephone number etc etc as well etc. zzapper> I seem to have trouble with double letter bindkeys , or zzapper> is this the old vi- edit mode problem? I use a pretty simple method, I just put echo in front of the string I like to save and execute that line. Then it will be in the history. I can search for these by back search the echo like: echo<M-p> Pretty easy. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it 2008-01-09 18:58 ` zzapper 2008-01-09 19:15 ` Paul Lew @ 2008-01-13 8:00 ` Bart Schaefer 2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David 2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl 1 sibling, 2 replies; 51+ messages in thread From: Bart Schaefer @ 2008-01-13 8:00 UTC (permalink / raw) To: zsh-users On Jan 9, 6:58pm, zzapper wrote: } } BTW you can use this as a temporary memory for a telephone number etc } etc as well etc. I don't know why I never thought of this before. --- 8< --- snip --- 8< --- #!/bin/zsh -f # A little zsh sticky-note ("post-it") application. Sticky notes are # stored in the file named by the STICKYFILE variable (defaults to # $HOME/.zsticky). The number of notes stored is STICKYSIZE (1000). # # May be bound as a widget: # zle -N sticky-note # And/or run as a command: # sticky-note # sticky-note -b # sticky-note -l ... # With the -l option, lists previous sticky notes. Most options of the # "fc -l" command are supported for selecting which notes to display. # The -b option is like "zed -b": installs keymaps/bindings only. # # Otherwise invokes the line editor with the previous notes available # as an editor history. Two quick taps on the return/enter key finish # the note, or you can use use ^X^W as usual (ZZ in vicmd mode). # I encourage all you creative people to contribute enhancements ... # no-prize for the first person to put the most recent sticky note in # his PS1 string. emulate -LR zsh local STICKYFILE=${STICKYFILE:-$HOME/.zsticky} local STICKYSIZE=${STICKYSIZE:-1000} # If invoked as a widget, behave a bit like run-help if zle then if [[ $CONTEXT = (cont|select|vared) ]] then zle -M "No stickies during ${${(z)PREBUFFER}[1]:-$CONTEXT}, sorry" zle .beep else zle .push-line BUFFER=sticky-note zle .accept-line fi return 0 fi (($+bg && $+fg)) || { autoload -U colors; colors } # Invoked as a command, behave like zed, but write a history file setopt extendedhistory nobanghist fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE # With a -l option, list the existing sticky notes if [[ "$1" == -l ]] then print -nr "$bg[yellow]$fg[black]" fc -f "$@" print -nr "$reset_color" return 0 fi # Set up keybindings (adapted from "zed") if ! bindkey -M sticky >& /dev/null then bindkey -N sticky main bindkey -M sticky ^X^W accept-line bindkey -M sticky ^M^M accept-line # Two quick RETs ends note bindkey -M sticky ^M self-insert-unmeta fi if ! bindkey -M sticky-vicmd >& /dev/null then bindkey -N sticky-vicmd vicmd bindkey -M sticky-vicmd ZZ accept-line fi [[ "$1" == -b ]] && return 0 # Edit a new sticky note and add it to the STICKYFILE local sticky while vared -h -p "%{$bg[yellow]$fg[black]%}" -M sticky -m sticky-vicmd sticky do { print -s -- "$sticky" } always { (( TRY_BLOCK_ERROR = 0 )) } && break echo -n -e '\a' done return 0 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: sticky-notes script [was: Zsh - push current command on history without executing it] 2008-01-13 8:00 ` Bart Schaefer @ 2008-01-15 22:57 ` Jean-Rene David 2008-01-16 8:06 ` Bart Schaefer 2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl 1 sibling, 1 reply; 51+ messages in thread From: Jean-Rene David @ 2008-01-15 22:57 UTC (permalink / raw) To: zsh-users * Bart Schaefer [1/13/2008 3:00 AM]: > # A little zsh sticky-note ("post-it") application. [snip beginning of script] > # Invoked as a command, behave like zed, but write a history file > setopt extendedhistory nobanghist > fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE This is very nice, but the line above gives me: sticky-notes:fc:49: not interactive shell I tried on both: zsh 4.3.4 (i686-pc-cygwin) zsh 4.2.0 (i386-redhat-linux-gnu) zsh won't let me "setopt interactive" in the script, so not sure what to try next. -- JR ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: sticky-notes script [was: Zsh - push current command on history without executing it] 2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David @ 2008-01-16 8:06 ` Bart Schaefer 0 siblings, 0 replies; 51+ messages in thread From: Bart Schaefer @ 2008-01-16 8:06 UTC (permalink / raw) To: zsh-users On Jan 15, 5:57pm, Jean-Rene David wrote: } } * Bart Schaefer [1/13/2008 3:00 AM]: } } > # Invoked as a command, behave like zed, but write a history file } > setopt extendedhistory nobanghist } > fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE } } This is very nice, but the line above gives me: } } sticky-notes:fc:49: not interactive shell Sorry; the #!/bin/zsh line was mostly just pro-forma, the script is really intended to be an autoloaded function: autoload -U sticky-note However, I believe you can fix the script by changing the #! line to #!/bin/zsh -fi I'll commit that change to CVS. ^ permalink raw reply [flat|nested] 51+ messages in thread
* sticky-note and zle bindings 2008-01-13 8:00 ` Bart Schaefer 2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David @ 2008-01-16 13:10 ` Andy Spiegl 2008-01-16 15:59 ` Bart Schaefer 1 sibling, 1 reply; 51+ messages in thread From: Andy Spiegl @ 2008-01-16 13:10 UTC (permalink / raw) To: zsh-users Hi Bart, > I don't know why I never thought of this before. Cooool! :-) But how can I bind "sticky-note -l" etc. to a key? Chau, Andy. -- Escape the "Gates" of Hell: LINUX, the choice of a GNU generation! ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: sticky-note and zle bindings 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 0 siblings, 1 reply; 51+ messages in thread From: Bart Schaefer @ 2008-01-16 15:59 UTC (permalink / raw) To: zsh-users On Jan 16, 2:10pm, Andy Spiegl wrote: } } But how can I bind "sticky-note -l" etc. to a key? Wrapper widget. Here's a function for one that might be useful, cribbed from the top part of sticky-note: #autoload if [[ "$CONTEXT" = (cont|select|vared) ]] then zle -M "No $WIDGET during ${${(z)PREBUFFER}[1]:-$CONTEXT}, sorry" zle .beep else zle .push-line BUFFER="sticky-note -l" zle .accept-line fi ^ permalink raw reply [flat|nested] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ messages in thread
* 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; 51+ 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] 51+ messages in thread
* 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-24 20:54 ` Richard Hartmann 2008-01-25 5:58 ` Bart Schaefer 1 sibling, 1 reply; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ messages in thread
[parent not found: <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com>]
* 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 0 siblings, 1 reply; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ messages in thread
* 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 2008-01-25 9:49 ` Richard Hartmann 1 sibling, 1 reply; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ 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; 51+ 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] 51+ messages in thread
end of thread, other threads:[~2008-06-27 16:26 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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-09 19:15 ` Paul Lew 2008-01-13 8:00 ` Bart Schaefer 2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David 2008-01-16 8:06 ` 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 2008-01-24 18:17 Robert Knight 2008-01-24 20:09 ` Richard Hartmann 2008-01-24 20:54 ` Richard Hartmann 2008-01-24 21:54 ` Robert Knight 2008-01-24 23:22 ` Richard Hartmann [not found] ` <13ed09c00801241857n2b1613f0m2d74fd12a90135cc@mail.gmail.com> 2008-01-25 9:32 ` Richard Hartmann 2008-01-25 17:57 ` Bart Schaefer 2008-01-25 18:18 ` Robert Knight 2008-01-26 2:12 ` Bart Schaefer 2008-01-26 15:41 ` Richard Hartmann 2008-01-26 23:31 ` Bart Schaefer 2008-01-28 16:33 ` Andy Spiegl 2008-06-07 4:39 ` Robert Knight 2008-06-10 4:13 ` Benjamin R. Haskell 2008-06-11 0:02 ` Richard Hartmann 2008-06-11 0:26 ` Benjamin R. Haskell 2008-06-11 1:17 ` Richard Hartmann 2008-06-11 4: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-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
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).