To Z Or Not To Z

Blasphemous Preist writes "For all of you looking for a good religious war over shells, IBM has just posted the following article on zsh. It's very informative and comes from a strong Linux and Z-shell proponent. If you're in to hack around with something other than bash zsh may be z answer."

Two things that alone is enough to use zsh

1.

~myhome% hash -d lbin=/usr/local/bin
~myhome% cd ~lbin
~lbin% pwd
/usr/local/bin

2.

/% gzip **/*.dvi

gives the same result as

/% find -name "*.dvi" -exec gzip {} \;

Re:Shells in a Nutshell

Of course, one of the main advantages of zsh is that it is rather compatible with both major shell tracks. You dont really have to 'learn' it, wether you're from the *csh or *sh track, because it will understand you fairly well either way.

Another feature that is nice is automatic sanity mode, which pretty much nullifies those times you have to stty this or that just because some vendor still hasnt gotten it right. Commandline editing and arrow keys work, whatever platform you're logging in from.

Just check the comp.sys.shells faq :). Which shell has the most features? Not that you'd ever use them all...

zsh is good if you have a HP/IBM/Sun workstation and you need a shell that will just work FOR you, and you dont have the time to spend to configure the various shells into something resembling a sane environment. It's the ultimate commandline environment.

For obvious reasons it isnt good for scripts that are to be deployed over various platforms, but then ksh is pretty much the least common denominator there. Altho considering the various vendor bugs in that you could probably just spend the time to install perl or bash across the platforms so you get a scripting language with the same bugs on all machines.

Zsh advocacy

I'm constantly surprised that Zsh doesn't receive more attention. I guess the major headache is the lack of accessible documentation which addresses the advantages.

I use it as my default shell everywhere I work, on both NT and Unix. Here's some of the features that I love:

Programmable Completion
You can define completion for different commands in different ways. eg.
ping/telnet completes with the list of machines on my network
man completes with my man pages
kill completes with job numbers

java completes with all my available Java classes (I have to provide a Perl utility to help with this (classfind [demon.co.uk]) though)

Recursive and intelligent wildcarding
ls **/* completes through directories, subdirectories and the like. I never really have to use find anymore
ls **/*(ah-5) finds files accessed within the last 5 hours
ls **/*(L0) finds files of zero length
ls **/*(@) finds symbolic links
etc.

Jerry Peek has quizzed the Zsh mailing lists for info so he can write about it in the next Unix Power Tools. Hopefully Zsh's profile will be raised somewhat.

Everyone missed zsh's best bits!

As one of the zsh developers (although admittedly one of the less active ones), I'm happy that zsh is getting the attention it deserves, although it would have been better timed to coincide with the imminent release of the 4.0 series.

Rather surprisingly, everyone seems to have missed the biggest advantages zsh has over the other shells. Please guys, go out and try the latest development version! The amount of work spent on the 3.1.x development series over the last few years has been monumental. We're now at 4.0.1-pre-2, and its feature set is so far ahead of 3.0.x (let alone bash/tcsh) it's not even funny.

For example, the article raves about programmable completion. Quite right too - I feel like crying every time I watch someone struggle without it (although as my cow-orkers well know, I'm a bit weird like that :-)

BUT! The article didn't mention that beginning in version 3.1.6, the completion system underwent a complete rewrite, and now has sophisticated out-of-the-box completions for over 400 commands. Typing a Perl one-liner and you get stuck after perl - because you can't remember which option letters to use? Hit TAB and you get a list of all of them plus explanations. Want to quickly browse the structures of some of your MySQL tables? Type mysqlshow , hit TAB, and you get a list of your databases to complete from. Choose one, hit TAB again, and you get a list of the tables within that database. Want to scp an awkwardly-named file from a remote machine? Type a few letters of it, hit TAB and zsh will connect to the remote machine, get a file list, and use it to complete the file so you don't have to type it.

If you want to know more, have a look at

http://adamspiers.org/computing/zsh/

Things have moved on a bit since I wrote it, but it should hopefully give you a taster.

The article also mentioned prompts ... Well, if you're into eye candy, there's also a prompt theming system which I confess to writing :-) ObScreenshot:

http://adamspiers.org/computing/zsh/files/prompt s/

Top 10 reasons for usung Z-Shell

10) precmd() calls commands before displaying the prompt
9) user binding of keys for command line editing
8) .zlogout
7) ignores duplicates in the history list
6) best prompt:
spider:src/linux/include/linux *
(cuts longer directory names)
5) compatible with Bourne Shell, works as expected
4) best completion
3) make |& less feeds stdout and and stdin into less, shorter than make 2>&1 | less
2) Z-Shell has the best vi emulation
1) more exclusive than vim ;-)

I recommend the stable version 3.0.8, zsh in distributions are often from the 3.1 branch. This version breaks my skeleton files and some things (vi binding) doesn't work as I'm used too.

You Post this at 2:47AM...

and you're asking whether "To Z Or Not To Z"?!

The answer is, of course, "Not To Z." It's St. Patrick's Day! Have another guinness. You have all Sunday afternoon to Z.

Shells in a Nutshell

Most developers and users of Linux come into contact with a UNIX shell sooner or later. This is typically in the form of the Bash shell, or sometimes the C shell, or Tcsh, or the Korn shell(the default on IBM's AIX operating system).

For the newbies, here's The_Messenger's Shells in a Nutshell:

All dominant shells are either Bourne shells or C shells. Bourne shells are descendants of the original sh, written by S.R. Bourne. The Bourne shell was a great scripting language (which resembles Modula-2), but was not well-suited for interactive use. The C Shell csh), written by Bill Joy, attempted to remedy this by providing such novel features as job control and was much nicer for the interactive user, but its C-like scripting language in the original implemenation was clumsy and buggy.

The KornShell (ksh), created by David Korn at AT&T, is the best of both worlds. It's a Bourne shell with tons of new scripting features, plus all of the C shell's interactive advantages. The KornShell is now the standard UNIX shell; you'll find it on all real (read: certified) UNIX systems, including Solaris. AIX, HP-UX, IRIX, SCO, et cetera.

Tcsh, the Tenex C shell, is a suped-up version of the Berkely C shell. I like to think of it as what the KornShell would have been if it were csh-based. This shell is not "standard" but is found on most UNIX systems regardless.

If you have to learn one shell, learn Korn. Why a Bourne shell? Because there are simply some times when you can't use a C-shell -- when editting the standard system scripts, for instance. Most of these scripts are written in the UNIX-vendor's sh implementation, which is different than Korn, but much closer to Korn than Tcsh. Why use Korn instead of just plain-old sh? Because sh is dreadful for interactive use!!

Now we come to bash. Bash is the GNU implementation of a Bourne shell, and is comparable to tcsh in its feature-set. Bash is the standard shell on GNU/Linux systems, as well as the shell which the GNU/Linux system scripts are written in, which is convenient.

However, many GNU/Linux newbies are under the impression that bash is the standard UNIX shell, which is NOT the case. There are endless differences; RTFM. The two good reasons to make your sysadmin install bash anyway are these: awesome command-line completion and the best EMACS command-line editor available!

C shells are by no means dead, however. FreeBSD, being loyal to its BSD roots, still uses a C shell as its default. (Although once again the system scripts are still in sh. ;-) Until FreeBSD 4.1, the default shell was the Berkely csh; in 4.1 and later, they use tcsh.

OpenBSD's standard shell is pdksh, a freeware clone of ksh. Personally, I find this shell obselete, because the real ksh is now (finally!) freely available from AT&T, and the pdksh is not KSH93-complaint.

So there are five shells you have an excuse for knowing: sh, csh, ksh, tcsh, and bash. (Gesundheit!)

The topic of this article is the Z shell, to which I say; Bah, humbug! While learning another shell might be a good way to spend a quiet weekend, the benefits are questionable. It's one which you'll never be guaranteed to have on a UNIX, GNU/Linux, or BSD system. You should only bother to learn a new shell if you're switching UNIX/Unixes or your current shell is missing features.

--