* Fw: Zsh - push current command on history without executing it
@ 2008-01-04 10:59 Peter Stephenson
2008-01-04 11:04 ` Mikael Magnusson
0 siblings, 1 reply; 22+ messages in thread
From: Peter Stephenson @ 2008-01-04 10:59 UTC (permalink / raw)
To: Zsh Users
Forwarded from someone presumably not on the list.
Begin forwarded message:
Date: Mon, 24 Dec 2007 03:59:55 +0200
From: Casper Gripenberg <casper.gripenberg@kotiportti.fi>
To: pws@zsh.org
Subject: Zsh - push current command on history without executing it
Hi..I was reading the zsh manual and trying to
figure out how to push the current command line
into the history list wihout actually executing
the command.
push-line does almost what I want, but it pops
the command back into view after I issue the next
command. What I'm looking for is something like
push-history.. but I can't find it. Is there
such a thing or any way to make zsh do something
like that?
Thanks.
Casper
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it
2008-01-04 10:59 Fw: Zsh - push current command on history without executing it Peter Stephenson
@ 2008-01-04 11:04 ` Mikael Magnusson
2008-01-04 11:24 ` Casper Gripenberg
0 siblings, 1 reply; 22+ messages in thread
From: Mikael Magnusson @ 2008-01-04 11:04 UTC (permalink / raw)
To: casper.gripenberg; +Cc: Zsh Users
---------- Forwarded message ----------
From: Chris Johnson <cjohnson@cs.utk.edu>
Date: 20 Dec 2007 19:26
Subject: Re: command-cancellation with #
To: Micah Elliott <mde@micahelliott.com>, zsh-users@sunsite.dk
Micah Elliott sent me the following 1.3K:
> On 2007-12-20 Mikael Magnusson wrote:
>
> > On 20/12/2007, Micah Elliott <mde@micahelliott.com> wrote:
> > > $ #ls foo
> > > zsh: bad pattern: #ls
> > >
> > > Is there a way to make this work in zsh the way it does in bash?
> >
> > setopt interactivecomments
>
> Great, that works. Thanks!
>
> Is there some way I could have discovered that? I don't see it
> in zshall(1). I do see that it (and a few others) are set now by
> running 'setopt', but it would be nice to know what all the
> available options are (which aren't in the manpage).
It's in my zshall, and more narrowly, in zshoptions.
For the functionality of "pausing" a command line, you can also bind the
push-line widget (check out the zshzle man page for key binding and
line-editing options) to temporarily interrupt a command so as to
execute another, and have the interrupted command return for editing
automatically. I bind this to Alt-Q (or Escape-Q):
bindkey "^[Q" push-line
And I have this custom widget to help me store a command line in history
without executing it:
commit-to-history() {
print -s ${(z)BUFFER}
zle send-break
}
zle -N commit-to-history
bindkey "^X^H" commit-to-history
So, I type a command, hit Ctrl-X Ctrl-H, and then retrieve my command
from history when I need it.
--
Chris Johnson
cjohnson@cs.utk.edu
http://www.cs.utk.edu/~cjohnson
On 04/01/2008, Peter Stephenson <pws@csr.com> wrote:
> Forwarded from someone presumably not on the list.
>
>
> Begin forwarded message:
>
> Date: Mon, 24 Dec 2007 03:59:55 +0200
> From: Casper Gripenberg <casper.gripenberg@kotiportti.fi>
> To: pws@zsh.org
> Subject: Zsh - push current command on history without executing it
>
>
>
> Hi..I was reading the zsh manual and trying to
> figure out how to push the current command line
> into the history list wihout actually executing
> the command.
>
> push-line does almost what I want, but it pops
> the command back into view after I issue the next
> command. What I'm looking for is something like
> push-history.. but I can't find it. Is there
> such a thing or any way to make zsh do something
> like that?
>
> Thanks.
>
> Casper
>
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it
2008-01-04 11:04 ` Mikael Magnusson
@ 2008-01-04 11:24 ` Casper Gripenberg
2008-01-09 18:58 ` zzapper
0 siblings, 1 reply; 22+ messages in thread
From: Casper Gripenberg @ 2008-01-04 11:24 UTC (permalink / raw)
To: Zsh Users
Mikael Magnusson wrote:
> [...]
> And I have this custom widget to help me store a command line in history
> without executing it:
>
> commit-to-history() {
> print -s ${(z)BUFFER}
> zle send-break
> }
> zle -N commit-to-history
> bindkey "^X^H" commit-to-history
>
> So, I type a command, hit Ctrl-X Ctrl-H, and then retrieve my command
> from history when I need it.
That's perfect. Thanks.
Casper
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it
2008-01-04 11:24 ` Casper Gripenberg
@ 2008-01-09 18:58 ` zzapper
2008-01-09 19:15 ` Paul Lew
2008-01-13 8:00 ` Bart Schaefer
0 siblings, 2 replies; 22+ messages in thread
From: zzapper @ 2008-01-09 18:58 UTC (permalink / raw)
To: zsh-users
Casper Gripenberg wrote in news:477E177A.3060303@kotiportti.fi:
> Mikael Magnusson wrote:
> > [...]
>> And I have this custom widget to help me store a command line in history
>> without executing it:
>>
>> commit-to-history() {
>> print -s ${(z)BUFFER}
>> zle send-break
>> }
>> zle -N commit-to-history
>> bindkey "^X^H" commit-to-history
>>
Good one,
BTW you can use this as a temporary memory for a telephone number etc etc as
well etc.
I seem to have trouble with double letter bindkeys , or is this the old vi-
edit mode problem?
--
zzapper
http://www.rayninfo.co.uk/vimtips.html
http://rayninfo.co.uk/tips/zshtips.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it
2008-01-09 18:58 ` zzapper
@ 2008-01-09 19:15 ` Paul Lew
2008-01-13 8:00 ` Bart Schaefer
1 sibling, 0 replies; 22+ messages in thread
From: Paul Lew @ 2008-01-09 19:15 UTC (permalink / raw)
To: zzapper; +Cc: zsh-users
>>>>> "zzapper" == zzapper <david@tvis.co.uk> writes:
zzapper> Casper Gripenberg wrote in news:477E177A.3060303@kotiportti.fi:
>> Mikael Magnusson wrote:
>> > [...]
>>> And I have this custom widget to help me store a command line
>>> in history without executing it:
>>>
>>> commit-to-history() {
>>> print -s ${(z)BUFFER}
>>> zle send-break
>>> }
>>> zle -N commit-to-history
>>> bindkey "^X^H" commit-to-history
>>>
zzapper> Good one, BTW you can use this as a temporary memory for
zzapper> a telephone number etc etc as well etc.
zzapper> I seem to have trouble with double letter bindkeys , or
zzapper> is this the old vi- edit mode problem?
I use a pretty simple method, I just put echo in front of the string
I like to save and execute that line. Then it will be in the history.
I can search for these by back search the echo like:
echo<M-p>
Pretty easy.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: Zsh - push current command on history without executing it
2008-01-09 18:58 ` zzapper
2008-01-09 19:15 ` Paul Lew
@ 2008-01-13 8:00 ` Bart Schaefer
2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David
2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl
1 sibling, 2 replies; 22+ messages in thread
From: Bart Schaefer @ 2008-01-13 8:00 UTC (permalink / raw)
To: zsh-users
On Jan 9, 6:58pm, zzapper wrote:
}
} BTW you can use this as a temporary memory for a telephone number etc
} etc as well etc.
I don't know why I never thought of this before.
--- 8< --- snip --- 8< ---
#!/bin/zsh -f
# A little zsh sticky-note ("post-it") application. Sticky notes are
# stored in the file named by the STICKYFILE variable (defaults to
# $HOME/.zsticky). The number of notes stored is STICKYSIZE (1000).
#
# May be bound as a widget:
# zle -N sticky-note
# And/or run as a command:
# sticky-note
# sticky-note -b
# sticky-note -l ...
# With the -l option, lists previous sticky notes. Most options of the
# "fc -l" command are supported for selecting which notes to display.
# The -b option is like "zed -b": installs keymaps/bindings only.
#
# Otherwise invokes the line editor with the previous notes available
# as an editor history. Two quick taps on the return/enter key finish
# the note, or you can use use ^X^W as usual (ZZ in vicmd mode).
# I encourage all you creative people to contribute enhancements ...
# no-prize for the first person to put the most recent sticky note in
# his PS1 string.
emulate -LR zsh
local STICKYFILE=${STICKYFILE:-$HOME/.zsticky}
local STICKYSIZE=${STICKYSIZE:-1000}
# If invoked as a widget, behave a bit like run-help
if zle
then
if [[ $CONTEXT = (cont|select|vared) ]]
then
zle -M "No stickies during ${${(z)PREBUFFER}[1]:-$CONTEXT}, sorry"
zle .beep
else
zle .push-line
BUFFER=sticky-note
zle .accept-line
fi
return 0
fi
(($+bg && $+fg)) || { autoload -U colors; colors }
# Invoked as a command, behave like zed, but write a history file
setopt extendedhistory nobanghist
fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE
# With a -l option, list the existing sticky notes
if [[ "$1" == -l ]]
then
print -nr "$bg[yellow]$fg[black]"
fc -f "$@"
print -nr "$reset_color"
return 0
fi
# Set up keybindings (adapted from "zed")
if ! bindkey -M sticky >& /dev/null
then
bindkey -N sticky main
bindkey -M sticky ^X^W accept-line
bindkey -M sticky ^M^M accept-line # Two quick RETs ends note
bindkey -M sticky ^M self-insert-unmeta
fi
if ! bindkey -M sticky-vicmd >& /dev/null
then
bindkey -N sticky-vicmd vicmd
bindkey -M sticky-vicmd ZZ accept-line
fi
[[ "$1" == -b ]] && return 0
# Edit a new sticky note and add it to the STICKYFILE
local sticky
while vared -h -p "%{$bg[yellow]$fg[black]%}" -M sticky -m sticky-vicmd sticky
do
{
print -s -- "$sticky"
} always {
(( TRY_BLOCK_ERROR = 0 ))
} && break
echo -n -e '\a'
done
return 0
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sticky-notes script [was: Zsh - push current command on history without executing it]
2008-01-13 8:00 ` Bart Schaefer
@ 2008-01-15 22:57 ` Jean-Rene David
2008-01-16 8:06 ` Bart Schaefer
2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl
1 sibling, 1 reply; 22+ messages in thread
From: Jean-Rene David @ 2008-01-15 22:57 UTC (permalink / raw)
To: zsh-users
* Bart Schaefer [1/13/2008 3:00 AM]:
> # A little zsh sticky-note ("post-it") application.
[snip beginning of script]
> # Invoked as a command, behave like zed, but write a history file
> setopt extendedhistory nobanghist
> fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE
This is very nice, but the line above gives me:
sticky-notes:fc:49: not interactive shell
I tried on both:
zsh 4.3.4 (i686-pc-cygwin)
zsh 4.2.0 (i386-redhat-linux-gnu)
zsh won't let me "setopt interactive" in
the script, so not sure what to try next.
--
JR
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sticky-notes script [was: Zsh - push current command on history without executing it]
2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David
@ 2008-01-16 8:06 ` Bart Schaefer
0 siblings, 0 replies; 22+ messages in thread
From: Bart Schaefer @ 2008-01-16 8:06 UTC (permalink / raw)
To: zsh-users
On Jan 15, 5:57pm, Jean-Rene David wrote:
}
} * Bart Schaefer [1/13/2008 3:00 AM]:
}
} > # Invoked as a command, behave like zed, but write a history file
} > setopt extendedhistory nobanghist
} > fc -ap $STICKYFILE $STICKYSIZE $STICKYSIZE
}
} This is very nice, but the line above gives me:
}
} sticky-notes:fc:49: not interactive shell
Sorry; the #!/bin/zsh line was mostly just pro-forma, the script is
really intended to be an autoloaded function:
autoload -U sticky-note
However, I believe you can fix the script by changing the #! line to
#!/bin/zsh -fi
I'll commit that change to CVS.
^ permalink raw reply [flat|nested] 22+ messages in thread
* sticky-note and zle bindings
2008-01-13 8:00 ` Bart Schaefer
2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David
@ 2008-01-16 13:10 ` Andy Spiegl
2008-01-16 15:59 ` Bart Schaefer
1 sibling, 1 reply; 22+ messages in thread
From: Andy Spiegl @ 2008-01-16 13:10 UTC (permalink / raw)
To: zsh-users
Hi Bart,
> I don't know why I never thought of this before.
Cooool! :-)
But how can I bind "sticky-note -l" etc. to a key?
Chau,
Andy.
--
Escape the "Gates" of Hell: LINUX, the choice of a GNU generation!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sticky-note and zle bindings
2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl
@ 2008-01-16 15:59 ` Bart Schaefer
2008-01-16 17:12 ` idea for new feature (was: Re: sticky-note and zle bindings) Andy Spiegl
0 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2008-01-16 15:59 UTC (permalink / raw)
To: zsh-users
On Jan 16, 2:10pm, Andy Spiegl wrote:
}
} But how can I bind "sticky-note -l" etc. to a key?
Wrapper widget. Here's a function for one that might be useful, cribbed
from the top part of sticky-note:
#autoload
if [[ "$CONTEXT" = (cont|select|vared) ]]
then
zle -M "No $WIDGET during ${${(z)PREBUFFER}[1]:-$CONTEXT}, sorry"
zle .beep
else
zle .push-line
BUFFER="sticky-note -l"
zle .accept-line
fi
^ permalink raw reply [flat|nested] 22+ messages in thread
* idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-16 15:59 ` Bart Schaefer
@ 2008-01-16 17:12 ` Andy Spiegl
2008-01-17 3:11 ` Bart Schaefer
0 siblings, 1 reply; 22+ messages in thread
From: Andy Spiegl @ 2008-01-16 17:12 UTC (permalink / raw)
To: zsh-users
Hi Bart,
> Wrapper widget.
Ok, thanks.
I just thought of another useful thingie using this technique:
How about saving the current directory (or even the whole directory stack) of
every zsh-instance so that it's possible to restore the status of all shells
after an (in)voluntary crash, like network splits or an X-server crash.
Of course the temporary data would have to be cleaned up when exiting the
shells normally. Something like the sessionstore.js of firefox.
Is that an imaginable feature?
Bye,
Andy.
--
Life is like a roll of toilet paper.
The closer it gets to the end, the faster it goes.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-16 17:12 ` idea for new feature (was: Re: sticky-note and zle bindings) Andy Spiegl
@ 2008-01-17 3:11 ` Bart Schaefer
2008-01-17 17:26 ` Andy Spiegl
2008-01-18 21:21 ` Richard Hartmann
0 siblings, 2 replies; 22+ messages in thread
From: Bart Schaefer @ 2008-01-17 3:11 UTC (permalink / raw)
To: zsh-users
On Jan 16, 6:12pm, Andy Spiegl wrote:
}
} How about saving the current directory (or even the whole directory
} stack) of every zsh-instance so that it's possible to restore the
} status of all shells after an (in)voluntary crash, like network splits
} or an X-server crash.
Of course this is what share_history and inc_append_history are in
part intended to accomplish.
The problem is that zsh can't do it by iself. So, your X server has
crashed and 20 shell windows went kablooie. Even if every zsh has
faithfully been recording its state somewhere, how does each new
xterm you launch on the retarted X desktop know which one of the 20
saved states it should restore?
This is actually made *worse* by the fact that many modern X desktops
have "session managers" that will remember the apps and placement of
your windows and re-launch them on restart, so you may have 20 new
xterms all examining the set of state files effectively at once.
Even supposing your session manager doesn't do this, and you have a
command to launch a new xterm for every state file and somehow pass it
(ZDOTDIR maybe?) the name of the file it should initialize, zsh can't
track window placements or much of anything else that would help you
to tell which window is which after they reappear.
The upshot is that this isn't a zsh feature -- it's a cooperative
feature that requires effort from both the shell and whatever other
user interface environment it's running inside. It's pretty simple
to dump state somewhere from the precmd() function, if only you know
what to do with it later.
One of my sysadmins back in grad school had a collection of csh scripts
read from his .login to do something like this, 20 years ago. I never
saw them in detail, but I got the impression that they were stashing
away data they'd extracted from the SunWindows environment on his old
Sun-1 desktop (before there was such a thing as a sparc chip or even
OpenWindows -- can you say "black-and-white bitmap"?). And he didn't
even have such a thing as precmd -- he was relying on aliases for "cd"
and the like.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 3:11 ` Bart Schaefer
@ 2008-01-17 17:26 ` Andy Spiegl
2008-01-18 2:12 ` Christopher Lord
2008-01-18 9:19 ` Bart Schaefer
2008-01-18 21:21 ` Richard Hartmann
1 sibling, 2 replies; 22+ messages in thread
From: Andy Spiegl @ 2008-01-17 17:26 UTC (permalink / raw)
To: zsh-users
On 2008-01-16, 19:11, Bart Schaefer wrote:
> Of course this is what share_history and inc_append_history are in
> part intended to accomplish.
Only for the command history, though.
I was thinking about the directory stack.
> The problem is that zsh can't do it by iself. So, your X server has
> crashed and 20 shell windows went kablooie. Even if every zsh has
> faithfully been recording its state somewhere, how does each new
> xterm you launch on the retarted X desktop know which one of the 20
> saved states it should restore?
You're right - that's too complex and depends heavily on the user environment.
But zsh could start the cooperation by providing the saved data and some kind
of mechanism of reading it back in to restore the directory stack.
Having that, it will be up to the users/terminal-guys/xserver-guys to use
that data. When they know that zsh provides this they might be interested
in using it.
> The upshot is that this isn't a zsh feature -- it's a cooperative
> feature that requires effort from both the shell and whatever other
> user interface environment it's running inside.
Right, so let's start. :-)
> It's pretty simple to dump state somewhere from the precmd() function
In a separate file for each zsh instance? Using the PID? Or a counter?
Or maybe some unique identifier for each instance, say shell1, shell2, ...
That way zsh could check at startup whether there is a state-file for
its name and read it back in. The unique name should probably be in
an environment variable. Hm, then in .xsession you would start several
xterms with shells like that:
ZSHNAME="shell-1" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-1"
ZSHNAME="shell-2" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-2"
How about that?
Bye,
Andy.
--
To err is human. To really screw it up takes a computer.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 17:26 ` Andy Spiegl
@ 2008-01-18 2:12 ` Christopher Lord
2008-01-18 9:19 ` Bart Schaefer
1 sibling, 0 replies; 22+ messages in thread
From: Christopher Lord @ 2008-01-18 2:12 UTC (permalink / raw)
To: zsh-users
I do something like this using gnu screen. I have 12 windows (one for
each F-key). Screen starts each shell with an environment variable
$WINDOW. It's just an integer representing each window. I have my
history set up to write to ~/.zshist/history.$WINDOW. Then each window
writes the history to it's own history file.
I currently don't persist the $PWD into a file, but I imagine it is
pretty trivial to accomplish — just write $PWD to a file
~/.zshist/curdir.$WINDOW on precmd.
On Jan 17, 2008 12:26 PM, Andy Spiegl <zsh.Andy@spiegl.de> wrote:
> On 2008-01-16, 19:11, Bart Schaefer wrote:
> > Of course this is what share_history and inc_append_history are in
> > part intended to accomplish.
> Only for the command history, though.
> I was thinking about the directory stack.
>
> > The problem is that zsh can't do it by iself. So, your X server has
> > crashed and 20 shell windows went kablooie. Even if every zsh has
> > faithfully been recording its state somewhere, how does each new
> > xterm you launch on the retarted X desktop know which one of the 20
> > saved states it should restore?
> You're right - that's too complex and depends heavily on the user environment.
> But zsh could start the cooperation by providing the saved data and some kind
> of mechanism of reading it back in to restore the directory stack.
>
> Having that, it will be up to the users/terminal-guys/xserver-guys to use
> that data. When they know that zsh provides this they might be interested
> in using it.
>
> > The upshot is that this isn't a zsh feature -- it's a cooperative
> > feature that requires effort from both the shell and whatever other
> > user interface environment it's running inside.
> Right, so let's start. :-)
>
> > It's pretty simple to dump state somewhere from the precmd() function
> In a separate file for each zsh instance? Using the PID? Or a counter?
> Or maybe some unique identifier for each instance, say shell1, shell2, ...
> That way zsh could check at startup whether there is a state-file for
> its name and read it back in. The unique name should probably be in
> an environment variable. Hm, then in .xsession you would start several
> xterms with shells like that:
> ZSHNAME="shell-1" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-1"
> ZSHNAME="shell-2" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-2"
>
> How about that?
>
> Bye,
> Andy.
>
> --
> To err is human. To really screw it up takes a computer.
>
--
Christopher Lord
(w) www.clawbox.com
(e) christopherlord@gmail.com
(w) 1-905-413-3765
(m) 1-416-788-2564
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 17:26 ` Andy Spiegl
2008-01-18 2:12 ` Christopher Lord
@ 2008-01-18 9:19 ` Bart Schaefer
2008-01-19 22:24 ` Andy Spiegl
1 sibling, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2008-01-18 9:19 UTC (permalink / raw)
To: zsh-users
On 1/17/08, Andy Spiegl <zsh.Andy@spiegl.de> wrote:
> > The upshot is that this isn't a zsh feature -- it's a cooperative
> > feature that requires effort from both the shell and whatever other
> > user interface environment it's running inside.
> Right, so let's start. :-)
Here's something that may be of use. Recent xterm has adopted window
control sequences from dtterm, according to
http://www.xfree86.org/current/ctlseqs.html, so zsh might have a
chance at saving/restoring some window state. I haven't tried Konsole
but Gnome-terminal pays attention to a subset of this. Other
terminals I don't know.
--- 8< --- snip --- 8< ---
#!/bin/zsh -f
# Implement two functions:
# xterm-tell control [args]
# xterm-ask control
# See xtermseq below for valid control names. -ask returns values in
$reply except for
# label and title which are returned in $REPLY.
# E.g. one way to maximize the window (see caveat below):
# xterm-ask screen_chars
# xterm-tell size_chars $reply
# Might there be terminfo names for these actions?
typeset -Ag xtermseq
xtermseq=(
1 deiconify 2 iconify
'3;X;Y' position
'4;H;W' size_pixels
5 raise 6 lower
7 refresh
'8;H;W' size_chars
'9;0' unmaximize '9;1' maximize
11 get_iconify
13 get_position
14 get_size_pixels
18 get_size_chars
19 get_screen_chars
20 get_label
21 get_title
)
local k
for k in ${(k)xtermseq}; do xtermseq[${xtermseq[$k]}]=$k; done
function xterm-tell {
local seq=${${${xtermseq[$1]:?no such command}/[HX]/$2}/[WY]/$3}
print -nr -- $'\e['${seq}t
}
function xterm-ask {
local esc
unset REPLY reply
1=get_${1#get_}
xterm-tell $1
case $1 in
(get_(label|title))
read -t 2 -rk 3 esc || return 1
read -rsd $'\e'
read -rk 1 esc
;;
(get_*)
read -t 2 -rk 2 esc || return 1
IFS=';' read -Arsd t
(( $#reply > 2 )) && shift reply
;;
esac
return 0
}
local documentation; read -rd $'\e' documentation <<'EOdoc' <<<$'\e'
CSI = "control sequence introducer": ESC [
OSC = "operating system command": ESC ]
ST = "string terminator": ESC backslash
Ps = "parameter string": (see list below)
All control sequences described here begin with CSI and end with "t".
Note that there are no spaces in control sequences or responses,
except possibly for the text responses for label and title; spaces
shown below are for readability.
Window manipulation (from dtterm, as well as extensions). These
controls may be disabled using the allowWindowOps resource. Valid
values for the first (and any additional parameters) are:
Ps = 1 -> De-iconify window.
Ps = 2 -> Iconify window.
Ps = 3 ; x ; y -> Move window to [x, y].
Ps = 4 ; height ; width -> Resize the xterm window in pixels.
Ps = 5 -> Raise the xterm window to the front of the stacking order.
Ps = 6 -> Lower the xterm window to the bottom of the stacking order.
Ps = 7 -> Refresh the xterm window.
Ps = 8 ; height ; width -> Resize the text area in characters.
Ps = 9 ; 0 -> Restore maximized window.
Ps = 9 ; 1 -> Maximize window (i.e., resize to screen size).
Ps = 1 1 -> Report xterm window state.
If the xterm window is open (non-iconified), returns CSI 1 t .
If the xterm window is iconified, returns CSI 2 t .
Ps = 1 3 -> Report xterm window position as CSI 3 ; x; yt
Ps = 1 4 -> Report xterm window in pixels as CSI 4 ; height ; width t
Ps = 1 8 -> Report size of text area as CSI 8 ; height ; width t
Ps = 1 9 -> Report size of screen in characters as CSI 9 ; height ; width t
Ps = 2 0 -> Report xterm window's icon label as OSC L label ST
Ps = 2 1 -> Report xterm window's title as OSC l title ST
Ps >= 2 4 -> Resize to Ps lines (DECSLPP)
The size of the screen in characters is often reported inaccurately.
Gnome-terminal as of v2.16 responds to 13/14/18/19 but fails to insert
the Ps digit 3/4/8/9 between the CSI and the reported dimensions, and
does not appear to respond to any of Ps in 1-9. Window managers may
also affect behavior; the Gnome desktop allows xterm to resize or
iconify itself but won't reliably let it reposition itself.
EOdoc
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-17 3:11 ` Bart Schaefer
2008-01-17 17:26 ` Andy Spiegl
@ 2008-01-18 21:21 ` Richard Hartmann
2008-01-19 21:46 ` Andy Spiegl
1 sibling, 1 reply; 22+ messages in thread
From: Richard Hartmann @ 2008-01-18 21:21 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
This is a re-send as I fail at replying to lists that do not munge
reply-to. Thanks to Bart for catching this.
On Jan 17, 2008 4:11 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is actually made *worse* by the fact that many modern X desktops
> have "session managers" that will remember the apps and placement of
> your windows and re-launch them on restart, so you may have 20 new
> xterms all examining the set of state files effectively at once.
If we were to define a sane setup, I am certain many newer terminals would
love to comply with it. It could be as easy as
SHELL_SESSION_COOKIE=`uuidgen`
with the magic cookie either generated or retrieved, whichever is applicable.
This could even be used to keep histories from merging indiscriminately on
shutdown & restart. The 'local' history could be made to appear at the 'end'
of the history buffer. If you were to hack up extendedhistory to also include
said magic cookie, this could allow for some _really_ interesting stuff.
Once Bash catches up to ZSH, they could use the same variables and
setup.
Richard
PS: I am pretty certain Robert Knight would love to implement this for
Konsole within seconds :)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-18 21:21 ` Richard Hartmann
@ 2008-01-19 21:46 ` Andy Spiegl
2008-01-19 23:05 ` Bart Schaefer
0 siblings, 1 reply; 22+ messages in thread
From: Andy Spiegl @ 2008-01-19 21:46 UTC (permalink / raw)
To: zsh-users
On 2008-01-18, 22:21, Richard Hartmann wrote:
> It could be as easy as
>
> SHELL_SESSION_COOKIE=`uuidgen`
>
> with the magic cookie either generated or retrieved, whichever is applicable.
Could you elaborate on the retrieval part? How do newly opened (after a
crash) shells know their cookie from before the crash?
Chau,
Andy.
--
"I would be willing to bet that >99% of the people that use PGP wouldn't
recognize a backdoor in the code if it fell on them." -Tim Mooney
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-18 9:19 ` Bart Schaefer
@ 2008-01-19 22:24 ` Andy Spiegl
2008-01-20 0:01 ` Bart Schaefer
0 siblings, 1 reply; 22+ messages in thread
From: Andy Spiegl @ 2008-01-19 22:24 UTC (permalink / raw)
To: zsh-users
On 2008-01-18, 01:19, Bart Schaefer wrote:
> Here's something that may be of use. Recent xterm has adopted window
> control sequences from dtterm, according to
> http://www.xfree86.org/current/ctlseqs.html, so zsh might have a
> chance at saving/restoring some window state. I haven't tried Konsole
> but Gnome-terminal pays attention to a subset of this. Other
> terminals I don't know.
This sounds very useful. But my xterm (v.231 from debian/unstable) don't
seem to understand theses control sequences yet. Do you know from which
version on it should be implemented?
It works with gnome-terminal, with konsole it doesn't.
But konsole must have some kind of state management because
my wife's KDE Desktop restores all shells including the PWD.
Chau,
Andy.
--
Assumption is the mother of all screw-ups.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-19 21:46 ` Andy Spiegl
@ 2008-01-19 23:05 ` Bart Schaefer
0 siblings, 0 replies; 22+ messages in thread
From: Bart Schaefer @ 2008-01-19 23:05 UTC (permalink / raw)
To: zsh-users
On Jan 19, 10:46pm, Andy Spiegl wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} On 2008-01-18, 22:21, Richard Hartmann wrote:
} > SHELL_SESSION_COOKIE=`uuidgen`
}
} Could you elaborate on the retrieval part? How do newly opened (after a
} crash) shells know their cookie from before the crash?
That's the part that would require cooperation from the X session
manager and/or the terminal emulator.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-19 22:24 ` Andy Spiegl
@ 2008-01-20 0:01 ` Bart Schaefer
2008-01-20 4:36 ` Matt Wozniski
0 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2008-01-20 0:01 UTC (permalink / raw)
To: zsh-users
On Jan 19, 11:24pm, Andy Spiegl wrote:
}
} This sounds very useful. But my xterm (v.231 from debian/unstable)
} don't seem to understand theses control sequences yet.
It's possible to configure xterm to not respond to these sequences,
and the window manager can suppress others.
} Do you know from which version on it should be implemented?
No, but another poster said it's been several years. I have what seems
to be v.192 (based on RPM version string) and it responds to all of
them except "get_title".
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-20 0:01 ` Bart Schaefer
@ 2008-01-20 4:36 ` Matt Wozniski
2008-01-20 9:09 ` Bart Schaefer
0 siblings, 1 reply; 22+ messages in thread
From: Matt Wozniski @ 2008-01-20 4:36 UTC (permalink / raw)
To: zsh-users
On Jan 19, 2008 7:01 PM, Bart Schaefer wrote:
> It's possible to configure xterm to not respond to these sequences,
> and the window manager can suppress others.
>
> } Do you know from which version on it should be implemented?
>
> No, but another poster said it's been several years. I have what seems
> to be v.192 (based on RPM version string) and it responds to all of
> them except "get_title".
Getting the title via control sequence is often compiled out for
security reasons. See http://securityvulns.com/Edocument128.html ,
the "window title reporting" section. The long and short of it is so
that a malicious text file, when cat'ed (or something similar), can't
set the title to a command, request the title (this putting the title
on the command line in the absense of a 'read'), and trick the user
into pressing enter.
~Matt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: idea for new feature (was: Re: sticky-note and zle bindings)
2008-01-20 4:36 ` Matt Wozniski
@ 2008-01-20 9:09 ` Bart Schaefer
0 siblings, 0 replies; 22+ messages in thread
From: Bart Schaefer @ 2008-01-20 9:09 UTC (permalink / raw)
To: zsh-users
On Jan 19, 11:36pm, Matt Wozniski wrote:
} Subject: Re: idea for new feature (was: Re: sticky-note and zle bindings)
}
} > except "get_title".
}
} The long and short of it is so that a malicious text file, when cat'ed
} (or something similar), can't set the title to a command, request the
} title (this putting the title on the command line in the absense of a
} 'read'), and trick the user into pressing enter.
I see the argument, but I don't think that's the case here, because
"get_label" (icon label) works fine; "print $'\e]0;ookatme\a\e[20t'"
puts "Lookatme" at my PS1 prompt.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-01-20 9:10 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-04 10:59 Fw: Zsh - push current command on history without executing it Peter Stephenson
2008-01-04 11:04 ` Mikael Magnusson
2008-01-04 11:24 ` Casper Gripenberg
2008-01-09 18:58 ` zzapper
2008-01-09 19:15 ` Paul Lew
2008-01-13 8:00 ` Bart Schaefer
2008-01-15 22:57 ` sticky-notes script [was: Zsh - push current command on history without executing it] Jean-Rene David
2008-01-16 8:06 ` Bart Schaefer
2008-01-16 13:10 ` sticky-note and zle bindings Andy Spiegl
2008-01-16 15:59 ` Bart Schaefer
2008-01-16 17:12 ` idea for new feature (was: Re: sticky-note and zle bindings) Andy Spiegl
2008-01-17 3:11 ` Bart Schaefer
2008-01-17 17:26 ` Andy Spiegl
2008-01-18 2:12 ` Christopher Lord
2008-01-18 9:19 ` Bart Schaefer
2008-01-19 22:24 ` Andy Spiegl
2008-01-20 0:01 ` Bart Schaefer
2008-01-20 4:36 ` Matt Wozniski
2008-01-20 9:09 ` Bart Schaefer
2008-01-18 21:21 ` Richard Hartmann
2008-01-19 21:46 ` Andy Spiegl
2008-01-19 23:05 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).