zsh tips for "UNIX Power Tools"

zsh tips for "UNIX Power Tools"

[Jerry Peek]

Hi.  I'm an occasional (*too* occasional, I'm afraid!) zsh user.
I'm also the first author of O'Reilly's "UNIX Power Tools" book
(http://www.oreilly.com/catalog/upt2/).  I'm just starting to work
on a third edition, due out (if all goes okay) sometime this fall.
I'd like to include basic coverage of zsh and cool zsh tips.

Before I get you all too excited ;-) here, I should say that UPT
probably won't be able to cover all zsh features: there are just too
many, and zsh still isn't as "mainstream" a shell as, say, bash.
We've gotta cover what readers are using!  And the book can't grow
too much; it's already pretty big.  But I do want to expose people
to other great tools, and zsh is sure one of those!  No idea yet how
many tips I can squeeze in, either: the outline isn't done.  Still,
I'm working zsh features into articles that describe other shells.

I don't know how active this list is, and I'm sorry if I jumped into
the wrong place.  But I'm actively working on the outline now, and I
just realized that you folks might be a great resource.  If you haven't
seen "UNIX Power Tools," it's basically a big collection of user tips.
I'm hoping that any of you who have some favorite zsh tips might have a
minute or two to send me a quick email with a description of the tip.
Also, I'm sure there must be some sites with collections of good zsh
tips (besides http://sunsite.auc.dk/zsh/, which I know about, of
course); if you have pointers, I'd be glad to get them.  I have the FAQ,
and I'll be going through the latest version as I work.  Still, as you
know if you've read UPT, some of the best tips may be things that aren't
"frequently asked."  So I thought you might have some cool ones to add.

I just joined the zsh-users list now -- but if it's too active, I may
have to unsubscribe because I get such a flood of email already.  So,
if you send a reply to the list, I'd appreciate a cc: jpeek@jpeek.com.

About compensation for your help:  O'Reilly & Associates have always
been big supporters of the open software community, and IMO they bend
over backwards to be fair.  The rules for compensating contributors
haven't been finalized yet.  What happened on the first couple of
editions was that we thank everyone, in print, for their contributions.
More-major contributors will probably get a free copy of the book...
and likely some money for *major* help (but there's probably not room
in UPT for that kind of help with zsh).  If you're concerned about
this before you contribute anything, I can try to help -- but I'm not
an O'Reilly employee (just an author under contract) so I can't give
official answers.  One more bit of administrivia: if you contribute
something that *you* wrote (vs. a pointer to tips elsewhere) we'll
need you to fill in a short permission/tracking form; please see
http://www.oreilly.com/oreilly/author/permission/source.html .

Thanks a lot.  I'm looking forward to finally getting zsh in UPT!

Jerry
-- 
Jerry Peek, jpeek@jpeek.com, http://www.jpeek.com/

Re: zsh tips for "UNIX Power Tools"

[Thomas Köhler]

On Thu, Mar 02, 2000 at 05:18:27PM +0100,
Jerry Peek <jpeek@jpeek.com> wrote:
> 
> Hi.  I'm an occasional (*too* occasional, I'm afraid!) zsh user.

Hi, I'm an all-day zsh user. :-)

> I'm also the first author of O'Reilly's "UNIX Power Tools" book
> (http://www.oreilly.com/catalog/upt2/).  I'm just starting to work
> on a third edition, due out (if all goes okay) sometime this fall.
> I'd like to include basic coverage of zsh and cool zsh tips.

I know about that book, but I don't have a copy of my own.
It's a cool book :)
(I already had in mind to buy a copy of my own, but there's always been
someone around who had it handy so I didn't buy it yet ;-)

> Before I get you all too excited ;-) here, I should say that UPT
> probably won't be able to cover all zsh features: there are just too
> many, and zsh still isn't as "mainstream" a shell as, say, bash.
> We've gotta cover what readers are using!  And the book can't grow
> too much; it's already pretty big.  But I do want to expose people
> to other great tools, and zsh is sure one of those!  No idea yet how
> many tips I can squeeze in, either: the outline isn't done.  Still,
> I'm working zsh features into articles that describe other shells.

A chapter of its own would be best, if that's possible. A short chapter
"zsh" would be better than lots of zsh tricks mangled into a bash
chapter.

> I don't know how active this list is, and I'm sorry if I jumped into
> the wrong place.

Well, it's surely the right place :-)

> But I'm actively working on the outline now, and I
> just realized that you folks might be a great resource.  If you haven't
> seen "UNIX Power Tools," it's basically a big collection of user tips.
> I'm hoping that any of you who have some favorite zsh tips might have a
> minute or two to send me a quick email with a description of the tip.

OK, I'm adding a few (very few) tips at the end of this mail.

[...]
> I just joined the zsh-users list now -- but if it's too active, I may
> have to unsubscribe because I get such a flood of email already.  So,
> if you send a reply to the list, I'd appreciate a cc: jpeek@jpeek.com.

I cc'ed you. But this list is usually not too busy, so I don't think you
have to unsubscribe again :-)

[...]
> official answers.  One more bit of administrivia: if you contribute
> something that *you* wrote (vs. a pointer to tips elsewhere) we'll
> need you to fill in a short permission/tracking form; please see
> http://www.oreilly.com/oreilly/author/permission/source.html .

I'm sitting behind UUCP, not having direct access to the internet now -
what's on that page? Would you mind sending me a copy?

> Jerry

CU,
Thomas

P.S.:
As for my zsh usage: I'm using zsh version 3.1.6-dev-19, and one of my
coolest things is beyond all basics and needs that version, but I
mention it anyways - perhaps someone on the list is interested, I don't
think that ones will make it into a book :)

My favorite zsh tricks (some of which are not too tricky, but perhaps
worth to be mentioned anyways):
- I like the globbing features of zsh, especially this one:
  for i in **/*.gif ; do convert $i ${i:r}.png ; done
  equivalent in bash:
  for i in `find . -name "*.gif"` ;
     do convert $i `basename $i .gif`.png
  done
  Howdy - we don't need basename, nor do we need find!
  And this one:
  chmod 755 **/*(/)
  chmod 644 **/*(.)
  Hey, all directories are mode 755, while all plain files are mode 644!
  Again, no find is necessary, as would be for bash:
  find . -type d -exec chmod 755 {} \;
  find . -type f -exec chmod 644 {} \;
- setopt rmstarsilent
  (I don't like this
   "sure you want to delete all the files in /home/jean-luc/foooooooo [yn]?"
  )
- bindkey "^X^H" run-help
  (this starts run-help on the command on the command-line. Pretty cool:
  it also works in pipes on the current command. See this example:
  ls -l | wc _
             ^- cursor here, now hit ^X^H (ctrl-x, followed by ctrl-h)
                -> the manpage for "wc" pops up
                Now exit man (by hitting 'q'), we're back to this:
  ls -l | wc _
  )
  Ah, and I have
  alias run-help=man
- Why not simply use ^Xh instead of ^X^H? Now, I have a feature of
  zsh-3.1.6-dev-xx on ^Xh:
  bindkey "^Xh" _complete_help
  Cooool! Help on completion! Sorry, only works for
  zsh-3.1.6-dev-something (don't remember the number) with the new-style
  completion, but I like it too much not to mention it here.
- emulate vim's g~ command - oops, it's already there, so it's easy:
  ###       vi-oper-swap-case
  ###              Read a movement command from the keyboard, and swap
  ###              the case of all characters from the cursor position
  ###              to the endpoint of the movement.  If  the  movement
  ###              command  is vi-oper-swap-case, swap the case of all
  ###              characters on the current line.
  bindkey -M vicmd "g~" vi-oper-swap-case
- precmd is the right place to do cool things like setting psvar - ready
  to be used in the right prompt:
  function precmd {
     # OK, I set the prompt here in my original precmd, but that's not the
     # issue here :)
     if jobs % >& /dev/null; then
        psvar=("There are jobs.")
     else
        psvar=("")
     fi
     # OK, what comes here? see next trick :)
     # SEE THERE
  }
  RPROMPT='%{^[[0;33m%}%1v%{^[[0m%}'
  Now this is cool! Whenever I have jobs, my right prompt indicates
  this.
- OK, now this one is long and only works with programmable widgets (so,
  only in zsh-3.1.6-dev-something), but there might be other people out
  there using this combination together with "bindkey -v". This is my
  last trick for now (and it contains some escape characters, so be sure
  to copy them as such if you want to try this):
  I have an indicator whether zle is in insert mode or command mode. It
  works like this:
  The last line in my precmd (marked "SEE THERE" above") reads like
  this:
     (sleep 1 ; show_mode "INSERT") &!
  [I need the sleep because I have a multiline prompt, so the show_mode
  would set the indication to the wrong place otherwise]
  I use this function for the indication:
  show_mode() {
     COL=$[COLUMNS-3]
     COL=$[COL-$#1]
     echo -n "^[7^[[1;A^[[$COL;G"
     echo -n "^[[0;37;44m--$1--^[[0m"
     echo -n "^[8"
  }

  Now here's the rewritten widgets:

  ###       vi-add-eol (unbound) (A) (unbound)
  ###              Move  to the end of the line and enter insert mode.
  vi-add-eol() {
     show_mode "INSERT"
     builtin zle .vi-add-eol
  }
  zle -N vi-add-eol
  bindkey -M vicmd "A" vi-add-eol

  ###       vi-add-next (unbound) (a) (unbound)
  ###              Enter insert mode after the  current  cursor  posi­
  ###              tion, without changing lines.
  vi-add-next() {
     show_mode "INSERT"
     builtin zle .vi-add-next
  }
  zle -N vi-add-next
  bindkey -M vicmd "a" vi-add-next

  ###       vi-change (unbound) (c) (unbound)
  ###              Read a movement command from the keyboard, and kill
  ###              from  the  cursor  position  to the endpoint of the
  ###              movement.  Then enter insert mode.  If the  command
  ###              is vi-change, change the current line.
  vi-change() {
     show_mode "INSERT"
     builtin zle .vi-change
  }
  zle -N vi-change
  bindkey -M vicmd "c" vi-change

  ###       vi-change-eol (unbound) (C) (unbound)
  ###              Kill  to the end of the line and enter insert mode.
  vi-change-eol() {
     show_mode "INSERT"
     builtin zle .vi-change-eol
  }
  zle -N vi-change-eol
  bindkey -M vicmd "C" vi-change-eol

  ###       vi-change-whole-line (unbound) (S) (unbound)
  ###              Kill the current line and enter insert mode.
  vi-change-whole-line() {
     show_mode "INSERT"
     builtin zle .vi-change-whole-line
  }
  zle -N vi-change-whole-line
  bindkey -M vicmd "S" vi-change-whole-line

  ###       vi-insert (unbound) (i) (unbound)
  ###              Enter insert mode.
  vi-insert() {
     show_mode "INSERT"
     builtin zle .vi-insert
  }
  zle -N vi-insert
  bindkey -M vicmd "i" vi-insert

  ###       vi-insert-bol (unbound) (I) (unbound)
  ###              Move to the first non-blank character on  the  line
  ###              and enter insert mode.
  vi-insert-bol() {
     show_mode "INSERT"
     builtin zle .vi-insert-bol
  }
  zle -N vi-insert-bol
  bindkey -M vicmd "I" vi-insert-bol

  ###       vi-open-line-above (unbound) (O) (unbound)
  ###              Open a line above the cursor and enter insert mode.
  vi-open-line-above() {
     show_mode "INSERT"
     builtin zle .vi-open-line-above
  }
  zle -N vi-open-line-above
  bindkey -M vicmd "O" vi-open-line-above

  ###       vi-open-line-below (unbound) (o) (unbound)
  ###              Open a line below the cursor and enter insert mode.
  vi-open-line-below() {
     show_mode "INSERT"
     builtin zle .vi-open-line-below
  }
  zle -N vi-open-line-below
  bindkey -M vicmd "o" vi-open-line-below

  ###       vi-substitute (unbound) (s) (unbound)
  ###              Substitute the next character(s).
  vi-substitute() {
     show_mode "INSERT"
     builtin zle .vi-substitute
  }
  zle -N vi-substitute
  bindkey -M vicmd "s" vi-substitute


  ###       vi-replace (unbound) (R) (unbound)
  ###              Enter overwrite mode.
  vi-replace() {
     show_mode "REPLACE"
     builtin zle .vi-replace
  }
  zle -N vi-replace
  bindkey -M vicmd "R" vi-replace

  ###       vi-cmd-mode (^X^V) (unbound) (^[)
  ###              Enter  command  mode;  that  is, select the `vicmd'
  ###              keymap.  Yes, this is bound  by  default  in  emacs
  ###              mode.
  vi-cmd-mode() {
     show_mode "NORMAL"
     builtin zle .vi-cmd-mode
  }
  zle -N vi-cmd-mode
  bindkey -M viins "^[" vi-cmd-mode

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

Re: zsh tips for "UNIX Power Tools"

[Jerry Peek]

Thanks for the tips, Thomas (or should I say Captain? :)  Two other
people have replied so far, and I'm getting a great list of tips.

> > Hi.  I'm an occasional (*too* occasional, I'm afraid!) zsh user.
> 
> Hi, I'm an all-day zsh user. :-)

With all I've been learning, I may become an all-day user too...

> A chapter of its own would be best, if that's possible. A short chapter
> "zsh" would be better than lots of zsh tricks mangled into a bash
> chapter.

Actually, shell techniques are spread through pretty much the whole
book.  We don't concentrate any shell into just one chapter... though
some chapters tend to have more shell-related stuff.  Thanks for the
comment, though.

> > need you to fill in a short permission/tracking form; please see
> > http://www.oreilly.com/oreilly/author/permission/source.html .
> 
> I'm sitting behind UUCP, not having direct access to the internet now -
> what's on that page? Would you mind sending me a copy?

No problem.  It's really short -- basically just your name and address,
plus a URL and website description if you refer me to something online.

Thanks again, and please keep those emails coming, all!

Jerry
-- 
Jerry Peek, jpeek@jpeek.com, http://www.jpeek.com/

Re: zsh tips for "UNIX Power Tools"

[Bruce Stephens]

Thomas Köhler <jean-luc@picard.franken.de> writes:

[...]

>   And this one:
>   chmod 755 **/*(/)
>   chmod 644 **/*(.)
>   Hey, all directories are mode 755, while all plain files are mode 644!
>   Again, no find is necessary, as would be for bash:
>   find . -type d -exec chmod 755 {} \;
>   find . -type f -exec chmod 644 {} \;

What's wrong with

        chmod -R go+rX .

However, wacky globbing is probably the thing that's special to zsh
that I consciously use.  OK, completion, too.

For example, a colleague was using some inferior shell (bash, I think)
and having to do things like:

        find . -type f -print | xargs grep -l ...

(It's painful to watch, sometimes.)  In zsh (for reasonably sized
trees, which I find are pretty common, YMMV): "grep -l ... **/*(.)".  

Yes, you can write little shell-scripts to do find ... | xargs, but **
(or ***) is just so much more convenient.  VMS had the right idea,
there.

Which of the directories is biggest?  "du -sk *(/)"
Which file has changed in the last couple of days? "echo *(m-2)"

And so on.  There are lots of really fancy things that zsh can do, but
I tend not to be able to remember them.  Simple stuff like the above
make it worthwhile to use, however, and the necessary syntax is very
easy to remember.



The stat dynamically loadable module is convenient for those operating
systems which don't have a stat executable.


I find these convenient:
        setopt autocd
        setopt autopushcd

I find this nice, but it's mostly cosmetic (path on the left is OK, too):
        RPROMPT="%~"


The built-in completion is excellent (that is, the scripts that are
supplied with 3.1.6-dev-18).  Peter Stephenson's guide to it shows a
number of nice tricks to changing its behaviour.

> - setopt rmstarsilent
>   (I don't like this
>    "sure you want to delete all the files in /home/jean-luc/foooooooo [yn]?"
>   )

Matter of taste.  I like it.


[...]

> - Why not simply use ^Xh instead of ^X^H? Now, I have a feature of
>   zsh-3.1.6-dev-xx on ^Xh:
>   bindkey "^Xh" _complete_help

Why not use M-h, which is built-in, I think.  I don't remember
configuring it, anyway.


[...]

Re: zsh tips for "UNIX Power Tools"

[Bart Schaefer]

On Mar 3, 12:39pm, Thomas Köhler wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} My favorite zsh tricks (some of which are not too tricky, but perhaps
} worth to be mentioned anyways):
} - I like the globbing features of zsh, especially this one:
}   for i in **/*.gif ; do convert $i ${i:r}.png ; done

It's even easier than that:

    for i in **/*.gif; convert $i $i:r.png

You don't need the "do ... done" for a one-liner.  (The no_short_loops
option can be used to require do ... done for ksh script compatibility.)
You don't need the { } for $i:r either (though you would if there were
not a "." between the "r" and the "png").

Skipping ahead just a bit:

} This is my last trick for now (and it contains some escape characters,
} so be sure to copy them as such if you want to try this)

Avoid literal escape characters in 3.1.6 and later by using $'...'.
The result of $'...' is that the stuff in between the single quotes is
treated as if you did $(print '...') instead.  So now \e is escape:

	RPROMPT=$'%{\e[0;33m%}%1v%{\e[0m%}'

}   function precmd {
}      # OK, I set the prompt here in my original precmd, but that's not the
}      # issue here :)
}      if jobs % >& /dev/null; then
}         psvar=("There are jobs.")
}      else
}         psvar=("")
}      fi
}   }

Two things:  First, you can assign directly to individual elements of an
array, thusly:

	psvar[1]="There are jobs."

That way you can use other positions in $psvar for other things, without
reassigning the whole thing every time.

Second, in 3.1.6-dev-19, you've got the parameter module available, so
you can avoid running the jobs command and even do some fancier stuff:

	# requires zmodload zsh/parameter
	case "$jobstates" in
	(*suspended*)
	  psvar[1]="There are stopped jobs.";;
	(*running*)
	  psvar[1]="There are running jobs.";;
	(*)
	  psvar[1]="";;
	esac

Note that if instead you'd said

	psvar[1]=()

then that's equivalent to

	shift psvar

which is probably not what you want in this case.

}   The last line in my precmd (marked "SEE THERE" above") reads like
}   this:
}      (sleep 1 ; show_mode "INSERT") &!
}   [I need the sleep because I have a multiline prompt, so the show_mode
}   would set the indication to the wrong place otherwise]

There's a better way to do this:

	# requires setopt prompt_subst
	PROMPT="$PROMPT"'%{$(show_mode INSERT >/dev/tty)%}'

Now the prompt itself runs the initial show_mode, and you don't need any
background jobs run from precmd.  Note that I wrapped it in %{...%} to
indicate that it shouldn't be counted when computing the prompt width.
The redirection to /dev/tty is so that the output of show_mode won't
really become part of the prompt.

}   ###       vi-add-eol (unbound) (A) (unbound)
}   ###              Move  to the end of the line and enter insert mode.
}   vi-add-eol() {
}      show_mode "INSERT"
}      builtin zle .vi-add-eol
}   }
}   zle -N vi-add-eol
}   bindkey -M vicmd "A" vi-add-eol

Note that "A" is already bound to vi-add-eol in the vicmd keymap, so you
don't need that bindkey command.  It's enough to replace the existing
widget of that name with "zle -N vi-add-eol".  Same goes for the rest
of these widgets, as far as I noticed.

On Mar 3, 11:05pm, Bruce Stephens wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} >   chmod 755 **/*(/)
} >   chmod 644 **/*(.)
} 
} What's wrong with
} 
}         chmod -R go+rX .

It changes the group and other execute permissions of plain files if the
user execute permission was already set.  That's obviously not what 644
accomplishes on plain files in Thomas's example.

Besides, not everyone has GNU chmod.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh tips for "UNIX Power Tools"

[Thomas Köhler]

On Sat, Mar 04, 2000 at 12:08:21AM +0100,
Bruce Stephens <bruce+zsh@cenderis.demon.co.uk> wrote:
> 
> Thomas Köhler <jean-luc@picard.franken.de> writes:
> 
> [...]
> 
> >   And this one:
> >   chmod 755 **/*(/)
> >   chmod 644 **/*(.)
> >   Hey, all directories are mode 755, while all plain files are mode 644!
> >   Again, no find is necessary, as would be for bash:
> >   find . -type d -exec chmod 755 {} \;
> >   find . -type f -exec chmod 644 {} \;
> 
> What's wrong with
> 
>         chmod -R go+rX .

It simply sets wrong permissions :-)
(and not every chmod has -R, which is bad)

[from "man chmod"]:
       The letters `rwxXstugo' select the new permissions for the
       affected users: [...] execute only if the file is a directory
       or already has execute permission for some user  (X)
Oops - there's already some plain file mode 755 which I want to have
mode 644 - your solution won't work...

> [...]
> 
> > - Why not simply use ^Xh instead of ^X^H? Now, I have a feature of
> >   zsh-3.1.6-dev-xx on ^Xh:
> >   bindkey "^Xh" _complete_help
> 
> Why not use M-h, which is built-in, I think.  I don't remember
> configuring it, anyway.

I don't like M-h :-)
(well, and I use ^X <something else> for further mappings, so it is
simply consistent)

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

Re: zsh tips for "UNIX Power Tools"

[Thomas Köhler]

On Sat, Mar 04, 2000 at 06:40:44AM +0100,
Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
> 
> On Mar 3, 12:39pm, Thomas Köhler wrote:
> } Subject: Re: zsh tips for "UNIX Power Tools"
> }
> } My favorite zsh tricks (some of which are not too tricky, but perhaps
> } worth to be mentioned anyways):
> } - I like the globbing features of zsh, especially this one:
> }   for i in **/*.gif ; do convert $i ${i:r}.png ; done
> 
> It's even easier than that:
> 
>     for i in **/*.gif; convert $i $i:r.png

Of course - but I tend not to remember this one because I have to use
bash on some systems (well, I hope this will change soon), thus I use
this "do...done" almost always :)

> You don't need the "do ... done" for a one-liner.  (The no_short_loops
> option can be used to require do ... done for ksh script compatibility.)
> You don't need the { } for $i:r either (though you would if there were
> not a "." between the "r" and the "png").

Well, I put the { } always, even if I don't need it (a strange habbit of
mine).

> Skipping ahead just a bit:
> 
> } This is my last trick for now (and it contains some escape characters,
> } so be sure to copy them as such if you want to try this)
> 
> Avoid literal escape characters in 3.1.6 and later by using $'...'.
> The result of $'...' is that the stuff in between the single quotes is
> treated as if you did $(print '...') instead.  So now \e is escape:
> 
> 	RPROMPT=$'%{\e[0;33m%}%1v%{\e[0m%}'

Ah. Missed that one. As I'm running out of time for quite a while now, I
only get a few changes to zsh, so I don't even get all those cool
features in my mind... bad luck for me :-(

> }   function precmd {
> }      # OK, I set the prompt here in my original precmd, but that's not the
> }      # issue here :)
> }      if jobs % >& /dev/null; then
> }         psvar=("There are jobs.")
> }      else
> }         psvar=("")
> }      fi
> }   }
> 
> Two things:  First, you can assign directly to individual elements of an
> array, thusly:
> 
> 	psvar[1]="There are jobs."

[...]
> Second, in 3.1.6-dev-19, you've got the parameter module available, so
> you can avoid running the jobs command and even do some fancier stuff:

Ah, now this is cool.

> 	# requires zmodload zsh/parameter
> 	case "$jobstates" in
> 	(*suspended*)
[...]
> 	esac

OK, adding the cases with running _and_ suspended jobs was easy now :-)

> Note that if instead you'd said
> 
> 	psvar[1]=()
> 
> then that's equivalent to
> 
> 	shift psvar
> 
> which is probably not what you want in this case.

Of course.

> }   The last line in my precmd (marked "SEE THERE" above") reads like
> }   this:
> }      (sleep 1 ; show_mode "INSERT") &!
> }   [I need the sleep because I have a multiline prompt, so the show_mode
> }   would set the indication to the wrong place otherwise]
> 
> There's a better way to do this:
> 
> 	# requires setopt prompt_subst
> 	PROMPT="$PROMPT"'%{$(show_mode INSERT >/dev/tty)%}'
> 
> Now the prompt itself runs the initial show_mode, and you don't need any
> background jobs run from precmd.  Note that I wrapped it in %{...%} to
> indicate that it shouldn't be counted when computing the prompt width.
> The redirection to /dev/tty is so that the output of show_mode won't
> really become part of the prompt.

Well, OK so far - but the indication still ends up in the wrong place
now. I have a prompt like this:
[more lines]
12:56pm  up 6 days, 13:17,  9 users,  load average: 0.27, 0.17, 0.11
502 jean-luc@picard (ttypts/15) ~>

I want the indication at the end of the "uptime" line, so using
  (sleep 1 ; show_mode "INSERT") &!
does exactly that: move the cursor one line up, to the end of line and
print the indication, and then put the cursor back. Running this as in
your suggestion won't work: the command is evaluated with the cursor
being in it's old position (before drawing the prompt), so the movement
(to place the indication) just moves to the wrong place. Or is there an
option to get around this problem which I also didn't see? :)

> }   ###       vi-add-eol (unbound) (A) (unbound)
> }   ###              Move  to the end of the line and enter insert mode.
> }   vi-add-eol() {
> }      show_mode "INSERT"
> }      builtin zle .vi-add-eol
> }   }
> }   zle -N vi-add-eol
> }   bindkey -M vicmd "A" vi-add-eol
> 
> Note that "A" is already bound to vi-add-eol in the vicmd keymap, so you
> don't need that bindkey command.  It's enough to replace the existing
> widget of that name with "zle -N vi-add-eol".  Same goes for the rest
> of these widgets, as far as I noticed.

Ah, of course - I played around with all those things a bit too much and
forgot to remove those lines from my .zshry later. Thanks for reminding
me :-)

One last thing: Bart, thanks for your cool and incredible tips on this
list. I learned much from you!

CU & thanks,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

Re: zsh tips for "UNIX Power Tools"

[Vincent Lefevre]

On Fri, Mar 03, 2000 at 23:05:42 +0000, Bruce Stephens wrote:
> I find this nice, but it's mostly cosmetic (path on the left is OK, too):
>         RPROMPT="%~"

I like prompt on the right too. I often use:

  PS1="%m:%30<...<%~%<<%0(?..[Failed %?])%(#.#.>) "
  RPS1="<%*"

We can have a prompt on the left (the normal prompt), a part of
the prompt on the right, but can we have one below, that won't
be corrupted by the completions?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Computer science / computer arithmetic / Arénaire project at LIP, ENS-Lyon

Re: zsh tips for "UNIX Power Tools"

[Bruce Stephens]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

[...]

> On Mar 3, 11:05pm, Bruce Stephens wrote:
> } Subject: Re: zsh tips for "UNIX Power Tools"
> }
> } >   chmod 755 **/*(/)
> } >   chmod 644 **/*(.)
> } 
> } What's wrong with
> } 
> }         chmod -R go+rX .
> 
> It changes the group and other execute permissions of plain files if the
> user execute permission was already set.  That's obviously not what 644
> accomplishes on plain files in Thomas's example.

Sure, the two aren't identical.  I suspect the latter is more often
what people want---it's usually what I want, anyway.

> Besides, not everyone has GNU chmod.

I think the behaviour is reasonably common.  Solaris 2.5.1 chmod also
works (although I don't see the +X behaviour in the manpage).

Re: zsh tips for "UNIX Power Tools"

[Bruce Stephens]

Thomas Köhler <jean-luc@picard.franken.de> writes:

> On Sat, Mar 04, 2000 at 12:08:21AM +0100,
> Bruce Stephens <bruce+zsh@cenderis.demon.co.uk> wrote:

[...]

> > What's wrong with
> > 
> >         chmod -R go+rX .
> 
> It simply sets wrong permissions :-)
> (and not every chmod has -R, which is bad)
> 
> [from "man chmod"]:
>        The letters `rwxXstugo' select the new permissions for the
>        affected users: [...] execute only if the file is a directory
>        or already has execute permission for some user  (X)
> Oops - there's already some plain file mode 755 which I want to have
> mode 644 - your solution won't work...

Yes, depends on what you're trying to do.  I was thinking of having a
tree of files and making them accessible to other people; you seem to
be thinking of having a tree of files which (incorrectly) are
executable (perhaps because they come from a zip file or something).

It's also doubtless the case that some chmod's don't have -R and/or X,
although Solaris 2.5.1 does, so it's not *just* GNU chmod that works.

Re: zsh tips for "UNIX Power Tools"

[Bart Schaefer]

On Mar 4,  1:05pm, Thomas Köhler wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} Of course [...]

I put in a lot of extra details for Jerry's benefit.

} > 	# requires setopt prompt_subst
} > 	PROMPT="$PROMPT"'%{$(show_mode INSERT >/dev/tty)%}'
} > 
} > Now the prompt itself runs the initial show_mode, and you don't need any
} > background jobs run from precmd.
} 
} Well, OK so far - but the indication still ends up in the wrong place

show_mode is a function; fiddle with it.  E.g. pass the number of lines
to move up as a second argument, or pass that second argument only when
in the prompt and don't move up a line when $# > 1, or ...

} One last thing: Bart, thanks for your cool and incredible tips on this
} list. I learned much from you!

My pleasure.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh tips for "UNIX Power Tools"

[Bart Schaefer]

On Mar 4,  4:38pm, Bart Schaefer wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} show_mode is a function; fiddle with it.  E.g. pass the number of lines
} to move up as a second argument, or pass that second argument only when
} in the prompt and don't move up a line when $# > 1, or ...

I just noticed a problem with this that I should have remembered: zsh
issues a clear-to-eol at every newline in a multiline prompt, so the
prompt will erase anything that's printed before it is drawn.

Thomas's sleep run from precmd appears to be the only workaround for
this, so I apologize for second-guessing.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh tips for "UNIX Power Tools"

[Bart Schaefer]

On Mar 4,  1:22pm, Vincent Lefevre wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} We can have a prompt on the left (the normal prompt), a part of
} the prompt on the right, but can we have one below, that won't
} be corrupted by the completions?

What does "corrupted by completions" mean?  Covered up by a listing?

Having a prompt below the normal prompt is very tricky, because the
output of any command that you run will begin on the same line where
the "below" part of the prompt is.  And of course if you edit a long
line or a multiline buffer, the line editor needs to use that line, so
there's really no way for zsh to "reserve" it.

Here's a trick (usable only in 3.1.6-dev-19 or thereabouts, and later)
that you may find interesting:

self-insert() {
    zle .self-insert
    [[ -o always_last_prompt ]] && zle -R '' "Line: $((${#LBUFFER//[^
]}+1)) / Column: ${#LBUFFER##*
}" || return 0
}
zle -N self-insert

(Yes, those embedded newlines really should be there.)

This uses the completion listing to keep a running display of the line
and column at which you most recently inserted a character.  ZLE knows
how big a buffer it's editing, so it always places this output below
the entire editable text.

Of course this erases any existing completion listing every time you
insert a character (though not every time you complete), but maybe you
can live with that.

Overriding the many other ZLE widgets to make motions, deletions, etc.
also update the line and column is left as an excercise for the reader.
Beware of other packages like `predict-on' (included with 3.1.6-dev-19)
that also may attempt to redefine bindings in incompatible ways.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh tips for "UNIX Power Tools"

[Vincent Lefevre]

On Sat, Mar 04, 2000 at 18:12:43 +0000, Bart Schaefer wrote:
> What does "corrupted by completions" mean?  Covered up by a listing?

In fact, I would like something similar to a status line which would
be at the bottom of the terminal. The completions should be inserted
between the prompt and the "status line". Same behavior for the
multiline buffer.

> Here's a trick (usable only in 3.1.6-dev-19 or thereabouts, and later)
> that you may find interesting:
[snip]

Thanks, I'll try when I install a dev version of zsh.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Computer science / computer arithmetic / Arénaire project at LIP, ENS-Lyon

Re: zsh tips for "UNIX Power Tools"

[Bart Schaefer]

On Mar 6, 12:19am, Vincent Lefevre wrote:
} Subject: Re: zsh tips for "UNIX Power Tools"
}
} > Here's a trick (usable only in 3.1.6-dev-19 or thereabouts, and later)
} > that you may find interesting:
} [snip]
} 
} Thanks, I'll try when I install a dev version of zsh.

I noticed after posting it that a better way to do

	zle -R '' ...
is
	zle -M ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh tips for "UNIX Power Tools"

[Thomas Köhler]

On Mon, Mar 06, 2000 at 12:20:40AM +0100,
Vincent Lefevre <vincent@vinc17.org> wrote:
> 
> On Sat, Mar 04, 2000 at 18:12:43 +0000, Bart Schaefer wrote:
> > What does "corrupted by completions" mean?  Covered up by a listing?
> 
> In fact, I would like something similar to a status line which would
> be at the bottom of the terminal. The completions should be inserted
> between the prompt and the "status line". Same behavior for the
> multiline buffer.

I used to use screen's hardstatus option for this, but then I ended up
using a multiline prompt with all that information in it...

(Newer versions of screen have that feature, I have
Screen version 3.09.05 (FAU) 1-Sep-99)

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships