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)

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

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

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