Fw: Zsh - push current command on history without executing it

Fw: Zsh - push current command on history without executing it

[Peter Stephenson]

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

Re: Fw: Zsh - push current command on history without executing it

[Mikael Magnusson]

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

Re: Fw: Zsh - push current command on history without executing it

[Casper Gripenberg]

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

Re: Fw: Zsh - push current command on history without executing it

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

Re: Fw: Zsh - push current command on history without executing it

[Paul Lew]

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

Re: Fw: Zsh - push current command on history without executing it

[Bart Schaefer]

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

Re: sticky-notes script [was: Zsh - push current command on history without executing it]

[Jean-Rene David]

* 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

Re: sticky-notes script [was: Zsh - push current command on history without executing it]

[Bart Schaefer]

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.

sticky-note and zle bindings

[Andy Spiegl]

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!

Re: sticky-note and zle bindings

[Bart Schaefer]

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

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

[Andy Spiegl]

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.

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

[Bart Schaefer]

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.

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

[Andy Spiegl]

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.

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

[Christopher Lord]

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

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

[Bart Schaefer]

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

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

[Andy Spiegl]

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.

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

[Bart Schaefer]

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

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

[Matt Wozniski]

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

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

[Bart Schaefer]

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. 

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

[Richard Hartmann]

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

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

[Andy Spiegl]

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

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

[Bart Schaefer]

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.

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

[Robert Knight]

Hi,

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

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

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

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

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

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

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

Regards,
Robert.

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

[Richard Hartmann]

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


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

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


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

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


Richard

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

[Richard Hartmann]

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

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

[Robert Knight]

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

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

Regards,
Robert.

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

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

[Richard Hartmann]

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


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

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


Richard

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

[Richard Hartmann]

On Jan 25, 2008 3:57 AM, Robert Knight <robertknight@gmail.com> wrote:


> There is a misunderstanding.  By "end the session", I meant ending a
> session and removing all data associated with it.  An analogy would be
> the option not to save the tabs in a web browser when closing it.
> Saving the session state would be the default behavior which would
> occur when logging out of the X session or closing the shell by
> sending SIGHUP for example.

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

One thing that would need to be decided is which sessions to delete
first. Oldest overall, oldest upate, smallest footprint, largest footprint
all have their respective merrits. Probably another option :)

Another thing to note is that some people would probably want to keep
the respective histories seperate, other would want to merge them on
session 'detach', still others would probably want to merge the
information on explicit session destruction.
Option one could be done by hand by the route of
  .zsh_history.$SHELL_SESSION_COOKIE
the others would probably, again, need options.


Richard

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

[Bart Schaefer]

(I never saw the original message from Robert Knight and it's not in the
list archives.)

On Jan 25, 10:32am, Richard Hartmann wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} On Jan 25, 2008 3:57 AM, Robert Knight <robertknight@gmail.com> wrote:
} 
} > There is a misunderstanding.  By "end the session", I meant ending a
} > session and removing all data associated with it.  An analogy would be
} > the option not to save the tabs in a web browser when closing it.
} > Saving the session state would be the default behavior which would
} > occur when logging out of the X session or closing the shell by
} > sending SIGHUP for example.

Shells are slightly different beasts than other applications.  If I
explicitly exit from a shell, I'm done with whatever that shell was
doing, and if I were to then start a new shell I wouldn't want it to
return to the context of the the last shell I exited; the chances are
very good that the new thing I'll be doing has nothing to do with
the last thing.

OTOH if my shell *windows* in a GUI environment are disconnected, or
the shell is killed by HUP, I probably didn't intentionally exit and I'd
like the state restored, to the extent possible, when the GUI resumes.
That applies whether the GUI session is exited abnormally or when I
choose "Log Out" from a menu.

This implies that commands in the .zlogout or equivalent need to be
able to determine what caused the shell to exit:  builtin command,
user-generated EOF (ctrl-D), real EOF on stdin, HUP signal, etc.

It also implies that the shell needs a way to tell the GUI environment
NOT to attempt, independently, to restore current directory, etc.
 
} One thing that would need to be decided is which sessions to delete
} first. Oldest overall, oldest upate, smallest footprint, largest
} footprint all have their respective merrits. Probably another option

Scriptable.  Don't bother trying to define this in the shell itself.

} Another thing to note is that some people would probably want to keep
} the respective histories seperate, other would want to merge them on
} session 'detach', still others would probably want to merge the
} information on explicit session destruction.
} Option one could be done by hand by the route of
}   .zsh_history.$SHELL_SESSION_COOKIE
} the others would probably, again, need options.

Again scriptable.

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

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

[Robert Knight]

Hi,

> Is what you mean that the shell needs to find out when it can "garbage
> collect" whatever data it has stored for a session that's never going
> to be resumed?

Yes.

> Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
> how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
> the path to it in the environment.

That would work when the shell is running locally, but what if the
shell is running on another system which the user is accessing via
ssh?  The terminal emulator doesn't have direct access to the remote
file system.

Since the shell is the program which is storing the data, I think it
makes sense for it to be responsible for deciding where to put it,
rather than the terminal.

> OTOH if my shell *windows* in a GUI environment are disconnected, or
> the shell is killed by HUP, I probably didn't intentionally exit and I'd
> like the state restored, to the extent possible, when the GUI resumes.

That is my thinking too.

Regards,
Robert.

On 25/01/2008, Bart Schaefer <schaefer@brasslantern.com> wrote:
> (I never saw the original message from Robert Knight and it's not in the
> list archives.)
>
> On Jan 25, 10:32am, Richard Hartmann wrote:
> } Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
> }
> } On Jan 25, 2008 3:57 AM, Robert Knight <robertknight@gmail.com> wrote:
> }
> } > There is a misunderstanding.  By "end the session", I meant ending a
> } > session and removing all data associated with it.  An analogy would be
> } > the option not to save the tabs in a web browser when closing it.
> } > Saving the session state would be the default behavior which would
> } > occur when logging out of the X session or closing the shell by
> } > sending SIGHUP for example.
>
> Shells are slightly different beasts than other applications.  If I
> explicitly exit from a shell, I'm done with whatever that shell was
> doing, and if I were to then start a new shell I wouldn't want it to
> return to the context of the the last shell I exited; the chances are
> very good that the new thing I'll be doing has nothing to do with
> the last thing.
>
> OTOH if my shell *windows* in a GUI environment are disconnected, or
> the shell is killed by HUP, I probably didn't intentionally exit and I'd
> like the state restored, to the extent possible, when the GUI resumes.
> That applies whether the GUI session is exited abnormally or when I
> choose "Log Out" from a menu.
>
> This implies that commands in the .zlogout or equivalent need to be
> able to determine what caused the shell to exit:  builtin command,
> user-generated EOF (ctrl-D), real EOF on stdin, HUP signal, etc.
>
> It also implies that the shell needs a way to tell the GUI environment
> NOT to attempt, independently, to restore current directory, etc.
>
> } One thing that would need to be decided is which sessions to delete
> } first. Oldest overall, oldest upate, smallest footprint, largest
> } footprint all have their respective merrits. Probably another option
>
> Scriptable.  Don't bother trying to define this in the shell itself.
>
> } Another thing to note is that some people would probably want to keep
> } the respective histories seperate, other would want to merge them on
> } session 'detach', still others would probably want to merge the
> } information on explicit session destruction.
> } Option one could be done by hand by the route of
> }   .zsh_history.$SHELL_SESSION_COOKIE
> } the others would probably, again, need options.
>
> Again scriptable.
>
> See Util/reporter in the zsh source distribution for examples of how to
> dump out various shell state.
>

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

[Bart Schaefer]

On Jan 25,  6:18pm, Robert Knight wrote:
}
} > Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
} > how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
} > the path to it in the environment.
} 
} That would work when the shell is running locally, but what if the
} shell is running on another system which the user is accessing via
} ssh?  The terminal emulator doesn't have direct access to the remote
} file system.

Well ... I can think of three cases.

(1) The emulator itself is running remotely and displaying on the local
desktop.  In this case the emulator *does* have access to the "remote"
filesystem, but the desktop manager can't restore such a window, so
there's nothing (special) for us to do.

(2) The emulator is local but the application is "ssh".  This is out of
our purview; ssh could propagate the SHELL_SESSION_* environment and it
would be up to sshd to do the right thing on the remote end as part of
its X11 protocol forwarding or whatever, but whether it does is not for
us to determine.

(3) The emulator is local and the shell is local, but within that shell
the user has started up "ssh" to somewhere.  Our responsibility ends
with making sure that the local shell can record its state, which may
include that it needs to start up an ssh process.  Beyond that point we
are back to case (2).

What other case do you envision where the emulator can usefully be
involved?
 
} Since the shell is the program which is storing the data, I think it
} makes sense for it to be responsible for deciding where to put it,
} rather than the terminal.

The shell DOES determine where to store the data.  The emulator (or the
desktop session) is just creating a semaphore file; think of it the same
way you'd think of .pid file in /var/run, except there's one for each
shell session.  Whether the shell uses it to stash data is secondary,
and up to the shell save-state implementation; I just threw that part
out as a suggestion because it avoids the shell itself needing to have
garbage-session collection code.

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

[Richard Hartmann]

On Jan 26, 2008 3:12 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:


> (1) The emulator itself is running remotely and displaying on the local
> desktop.  In this case the emulator *does* have access to the "remote"
> filesystem, but the desktop manager can't restore such a window, so
> there's nothing (special) for us to do.

Terminals could keep a session state for themselves, so if I ran

  konsole --restore-session foo

it could restore everything, no matter if it is local and under the
desktop manager's control or not. This might even make the overall
terminal session handling cleaner.


> (2) The emulator is local but the application is "ssh".  This is out of
> our purview; ssh could propagate the SHELL_SESSION_* environment and it
> would be up to sshd to do the right thing on the remote end as part of
> its X11 protocol forwarding or whatever, but whether it does is not for
> us to determine.

Well, as soon as the shell see the appropriate variables, it can just do
whatever it was set up to do in that case, so this case should be transparent.


> (3) The emulator is local and the shell is local, but within that shell
> the user has started up "ssh" to somewhere.  Our responsibility ends
> with making sure that the local shell can record its state, which may
> include that it needs to start up an ssh process.  Beyond that point we
> are back to case (2).

Yes.


Restoring the programs that ran is a very interesting idea. I like it :)


> What other case do you envision where the emulator can usefully be
> involved?

Atm, none.


> The shell DOES determine where to store the data.  The emulator (or the
> desktop session) is just creating a semaphore file; think of it the same
> way you'd think of .pid file in /var/run, except there's one for each
> shell session.  Whether the shell uses it to stash data is secondary,
> and up to the shell save-state implementation; I just threw that part
> out as a suggestion because it avoids the shell itself needing to have
> garbage-session collection code.

If the shell is a child of ssh, there is no terminal to help the shell with
garbage collection, should it must be able to do this by itself, anyway.
Of course, the HANDLER variable could be used to determine who
should actually do the collection if both the terminal and the shell offer
this.


Richard

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

[Bart Schaefer]

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

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

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

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

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

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

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

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

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

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

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

On Jan 26,  4:41pm, Richard Hartmann wrote:
} 
} Restoring the programs that ran is a very interesting idea. I like it :)

Not "the programs that ran".  The programs that *were running*; that is,
something the shell had to SIGHUP when it exited.  I'd be very leery of
automatically restarting anything other than the foreground job, though,
and maybe not even that if it was a pipeline.

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

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

-- 

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

[Andy Spiegl]

On 2008-01-26, 15:31, Bart Schaefer wrote:
> } Restoring the programs that ran is a very interesting idea. I like it :)
> 
> Not "the programs that ran".  The programs that *were running*; that is,
> something the shell had to SIGHUP when it exited.  I'd be very leery of
> automatically restarting anything other than the foreground job, though,
> and maybe not even that if it was a pipeline.

I really like the idea of restoring the program that was running
before the "crash", but I'd suggest not to reexecute it (which may
have fatal side effects) but just putting it on the command line.
The user can then decide whether to press enter or not.

Chau,
 Andy.

-- 
 Once you've seen one shopping center you've seen a mall.

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

[Robert Knight]

Hi folks,

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

(1)  The terminal emulator creates a unique alphanumeric ID string for each
new session and passes it to the shell as an environment variable
$SHELL_SESSION_ID.
When the shell is killed via a SIGHUP it saves that state and the
associated session ID.
When restoring that session, the terminal emulator starts a new
instance of the shell as
usual, with the previously used $SHELL_SESSION_ID value.  The shell
looks for state saved
under that name and restores the previous state.  If no state is saved
against the id then
the shell can assume that it is a new session.  The ID would be
alphanumeric, with no fixed
length or format.  I would probably use Qt's UUID generator to come up
with something suitable
but users might choose human-readable names if they wanted to do their
own session management.

(2)  The terminal emulator specifies a file for the shell to save its
state information
to.  If the file is empty or does not exist then the shell assumes
this is a new session.  Otherwise it restores the contents of the
file.  The save/restore handling then works as in (1).

I favour the first option because the shell can pick a suitable place
to store its
state information which is in the same location/format as the rest of
its data.  Unlike a filename, an ID also works over remote
connections.

Policies over exactly what gets saved and restored and how long that
information should be kept for would be left up to the shell to begin
with.
I can make suggestions about what would be most useful however,
roughly in priority order.
The real gist is to minimize the time spent doing repetetive setup
routines to prepare for
working on various tasks.

- Environment variables (probably not the complete environment but
rather a delta between
the environment inherited by the shell when it started and the
environment in the shell when
it was closed)
- Prompt
- Aliases
- Functions

Digging back through my mail from users, something which would earn
much love from sysadmins
would be if they could save the state of their terminal, with 10-20
connections to various
machines via SSH and later restore that again instantly - including as
much state as possible
on the remote end.

Regards,
Robert.

2008/1/28 Andy Spiegl <zsh.Andy@spiegl.de>:
> On 2008-01-26, 15:31, Bart Schaefer wrote:
>> } Restoring the programs that ran is a very interesting idea. I like it :)
>>
>> Not "the programs that ran".  The programs that *were running*; that is,
>> something the shell had to SIGHUP when it exited.  I'd be very leery of
>> automatically restarting anything other than the foreground job, though,
>> and maybe not even that if it was a pipeline.
>
> I really like the idea of restoring the program that was running
> before the "crash", but I'd suggest not to reexecute it (which may
> have fatal side effects) but just putting it on the command line.
> The user can then decide whether to press enter or not.
>
> Chau,
>  Andy.
>
> --
>  Once you've seen one shopping center you've seen a mall.
>

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

[Benjamin R. Haskell]

On Sat, 7 Jun 2008, Robert Knight wrote:

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

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


> [...]
>
> Digging back through my mail from users, something which would earn much 
> love from sysadmins would be if they could save the state of their 
> terminal, with 10-20 connections to various machines via SSH and later 
> restore that again instantly - including as much state as possible on 
> the remote end.

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

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

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


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

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

Best,
Ben

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

[Richard Hartmann]

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


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

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


> Have you tried 'screen'?

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


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

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


Richard

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

[Benjamin R. Haskell]

On Wed, 11 Jun 2008, Richard Hartmann wrote:

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

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


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

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

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

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


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

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

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

Best,
Ben

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

[Richard Hartmann]

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


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

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


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

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


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

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


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

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


Richard

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

[Bart Schaefer]

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

If you go here ...

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

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

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

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

[Benjamin R. Haskell]

On Tue, 10 Jun 2008, Bart Schaefer wrote:

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

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

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

[Angel Olivera]

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

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

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

-- 
redondos

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

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

[Richard Hartmann]

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


> I favour the first option because the shell can pick a suitable place
> to store its
> state information which is in the same location/format as the rest of
> its data.  Unlike a filename, an ID also works over remote
> connections.

I prefer a variable, as well.


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

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


Richard

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

[Richard Hartmann]

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

> I'd like to implement my part of this quite soon.  So here is a more
> concrete proposal:
>
> (1)  The terminal emulator creates a unique alphanumeric ID string for each
> new session and passes it to the shell as an environment variable
> $SHELL_SESSION_ID.

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

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


Richard

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

[Richard Hartmann]

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

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

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


Richard

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

[Richard Hartmann]

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


> Shells are slightly different beasts than other applications.  If I
> explicitly exit from a shell, I'm done with whatever that shell was
> doing, and if I were to then start a new shell I wouldn't want it to
> return to the context of the the last shell I exited; the chances are
> very good that the new thing I'll be doing has nothing to do with
> the last thing.

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


> OTOH if my shell *windows* in a GUI environment are disconnected, or
> the shell is killed by HUP, I probably didn't intentionally exit and I'd
> like the state restored, to the extent possible, when the GUI resumes.
> That applies whether the GUI session is exited abnormally or when I
> choose "Log Out" from a menu.

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


> This implies that commands in the .zlogout or equivalent need to be
> able to determine what caused the shell to exit:  builtin command,
> user-generated EOF (ctrl-D), real EOF on stdin, HUP signal, etc.

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


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

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


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

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


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

Will do, thanks :)


Richard

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

[Clint Adams]

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

Yes, I pass LANG and LC_* when permitted.

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

[Richard Hartmann]

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


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

Perfect :)

Can you toss a snippet onto this list, please?


Richard

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

[Richard Hartmann]

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


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

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


Richard

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

[Bart Schaefer]

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

So in this scheme the terminal emulator creates the SHELL_SESSION_ID
and places it in the environment when the shell is started?  I.e.,
Konsole would be responsible for telling the shell which session to
resume (or to start a new one)?

If that's not what you mean, can you be more specific?

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

I'm not sure I follow the nuances here.  If a single window closes
before the user shuts his whole desktop session down, then the session
for that window ends, doesn't it?  Regardless of what application is
the creator of that window?

Is what you mean that the shell needs to find out when it can "garbage
collect" whatever data it has stored for a session that's never going
to be resumed?

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

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

Of course I may be completely in left field here.

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

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

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

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

Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
the path to it in the environment.  The shell can then choose to put
its session data in that file, or put it somewhere else and use the
file as a semaphore.  If the emulator (or the desktop session, even)
decides that the shell session has ended, it removes that file.  If
the shell stored its data in the file, the session is gone.  If it
used the file as a semaphore it can garbage-collect any session data
for which the file no longer exists.  (The file would have to be in a
predictable location (SHELL_SESSION_DIR ?) for the latter to work.)

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

[Richard Hartmann]

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


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

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


> I'm not sure I follow the nuances here.  If a single window closes
> before the user shuts his whole desktop session down, then the session
> for that window ends, doesn't it?  Regardless of what application is
> the creator of that window?
>
> Is what you mean that the shell needs to find out when it can "garbage
> collect" whatever data it has stored for a session that's never going
> to be resumed?

Yes, the garbage collection is the issue, here.


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

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

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


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

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


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

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


> Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
> how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
> the path to it in the environment.  The shell can then choose to put
> its session data in that file, or put it somewhere else and use the
> file as a semaphore.  If the emulator (or the desktop session, even)
> decides that the shell session has ended, it removes that file.  If
> the shell stored its data in the file, the session is gone.  If it
> used the file as a semaphore it can garbage-collect any session data
> for which the file no longer exists.  (The file would have to be in a
> predictable location (SHELL_SESSION_DIR ?) for the latter to work.)

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


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


Richard

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

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

[Bastian, Waldo]

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

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

Please post to xdg@lists.freedesktop.org to have your spec reviewed.

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

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

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


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

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


> I'm not sure I follow the nuances here.  If a single window closes
> before the user shuts his whole desktop session down, then the session
> for that window ends, doesn't it?  Regardless of what application is
> the creator of that window?
>
> Is what you mean that the shell needs to find out when it can "garbage
> collect" whatever data it has stored for a session that's never going
> to be resumed?

Yes, the garbage collection is the issue, here.


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

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

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


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

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


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

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


> Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
> how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
> the path to it in the environment.  The shell can then choose to put
> its session data in that file, or put it somewhere else and use the
> file as a semaphore.  If the emulator (or the desktop session, even)
> decides that the shell session has ended, it removes that file.  If
> the shell stored its data in the file, the session is gone.  If it
> used the file as a semaphore it can garbage-collect any session data
> for which the file no longer exists.  (The file would have to be in a
> predictable location (SHELL_SESSION_DIR ?) for the latter to work.)

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


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


Richard

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

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

[Richard Hartmann]

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


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

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


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

Even though this looks kinda comical, wouldn't

  $XDG_DATA_HOME/$XDG_SESSION_SHELL_DIR/$XGD_SESSION_SHELL_ID

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


Richard