Slashdot Mirror
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."
Don't you know Windows 2000's dos prompt is more powerful than your silly shells. You just have to know how to use it. It has commands like ping (to test if a host is up) doskey (so up arraw displays last command) and exit (closes windows automtically without clicking anything) And windows has been able to do this for years, but on windows 2000 microsoft has innovated again by giving the user the freedom to choose blue or black background to the text! In the mean time silly linux users argue and can't even decide on one shell while microsoft has had the best one all along!
Another of my favorite zsh features is shared history. Zsh can be set up to share one command-line history list amoung all the zsh's you have running. So all of my xterms share the same history and I don't have to remember in which one I ran what command.
Tcsh, the Tenex C shell
I thought the t was for tectronix.
Wansu, th' chinese sailor
I believe that if you call bash with the name sh (as all the system scripts will) it runs in sh-compatibility mode. I don't think that changes a lot, and I don't know if it removes features that are strictly a superset of sh's features, but it does make some difference.
Tcl is often considered to be too much of a toy language, but I think as a shell it would actually fit quite nicely. And for all its toyness, it's actually quite elegantly simple and easy to understand.
It expands to all the argument passed to the current program or function, just with different quoting semantics to $*. Your point being?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Putting a user-interface preference into the file system is a really stupid thing to do and NT should be blasted for it. However I would agree that Unix shells and file choosers could make the assumption that people may mistype the case of their filenames and it should be fixed. While they are at it they could do spelling correction and other such stuff (I bet you think the file system should do spelling correction too, since you think the case-insensitive parts of it are a big win, huh?)
NT does not accurately transform letters between case for Unicode at the filesystem level. They have decided (quite rightly) that doing this is an enormous security hole (because of different systems getting the rules differently and thus failing to notice that a program is going to clobber an existing file).
The proper place to do anything complex like this is at the user level. Unfortunately NT is forced to be back-compatable with their case-insensiteve file system so the case matching is rather complex and spread between two systems.
Unix design is in fact correct, where the filenames are a stream of bytes. The interpreteation of these bytes should be left for the user level.
A legitimate complaint would be that the Unix programmers keep neglecting to put such stuff into the user level. That is true. But the NT file system is wrong, and the engineers at MicroSoft are well aware of this fact.
I do think there is a legitimate complaint that the user level programs do not do more to help people with case-insensitve searches. They also don't handle spelling errors very well either.
However there is no reason to put case-insensitive rules into the file system itself. It is actually counter-productive for real case insensitivity since it often precludes making smarter front ends since it hides information (NT has some difficulty here). Also the rules for Unicode/UTF-8 are FAR too complex to rely on in code like a filesystem which security relies on.
My personal preference is for partial case-insensitivity: lower-case that I type in matches both upper and lower case, but upper case matches only upper case. This was the rules for the Final Word word processor I worked on in 1985, but for some reason these rules have totally disappeared from modern software. It worked great because it would find words at the start of sentences, but you could search for proper names (or sentence starts), and we didn't need a "case insensitive" switch.
In any case, no matter what the ideal user experience is, it definately should be moved out of low-level things like the file system. NT has got to fix this or they are going to get killed with security problems, especially in a hetrogenous environment of shared file systems.
All of these shells have been ported to NT, so in fact you get exactly the same question there as well.
Everybody realized pretty quickly that partial completion is far better. Of course MicroSoft is pretty far behind (for mysterious reasons, certainly there was somebody there who had used Unix file completion, and could have told them how to do it right...)
I believe they all are wrong, as I would prefer the assignment of meaning to these bytes be moved out of the file system and into user space. The reason is that there is far more complex matching rules (such as spelling correction and full UTF-8 case independence) that need to be done as well, and a partial solution like this is worse than none at all.
You can name the files with any of these letters, yes. But I was talking about the case-independence. At the file system level they only map case between the first 255 characters that are ISO-8859-1. This is a very smart decision, as the exact mapping for the rest of Unicode is not defined yet!
The problem with NT, etc, is that they assign meaning to those bits stored in the directory at a very low level. This prevents usage of those bits for more general purposes, and prevents smarter assignment of meaning at higher levels. If NT had stored raw 8-bit data like Unix does, they could have supported Unicode with NO CHANGES TO THE FILE SYSTEM (this would be done by using UTF-8, which also has the advantage of being upwardly-compatable with 8-bit names).
I totally agree that Unix user-level programs are written by lazy programmers who think that making it hard to use is kool. It is amazing that case-independent filename completion has taken so long and is still not the default for these shells. But for too long everybody has attacked this with equally lazy and very wrong ideas where this is stuffed into the file system.
Your terminology is wrong. Unix is case-preserving. The systems you are talking about (and also some Unix filesystems like AFS) are case-preserving + case-independent. Old MSDOS file systems were only case-independent but not case-preserving.
I also find it interesting that you are so enamored of an NT feature that is useless except for command line programs. The "overwhelming majority" of people click on files and would never notice if there were several files with the same name, and are not going to be bothered because both "Buffalo" and "buffalo" exist.
You're not 'guaranteed' to have zsh on any given system, but the same goes for any shell except plain /bin/sh. (Ksh is not usually there on Linux; bash is not usually there on proprietary *nix.) What you do is use bash and, if you want your scripts to be portable, restrict yourself to the standard Bourne-shell features. But there is nothing to stop you doing the same with zsh, since it is pretty much a superset of ksh (and thus a superset of sh).
OTOH, if you aren't concerned with writing portable shell scripts, why deny yourself the benefits of a nicer shell for interactive use? Maybe it is not worth 'learning' zsh as some kind of chore or training exercise, but if there's a feature you would like to use, go and use it. If people took the same viewpoint with all software - don't bother learning it unless it is there on all Unixes - 90% of the stuff on a typical Linux system would disappear.
Finally, it's not usually hard to install something like zsh. Not hard at all on Linux, and Linux makes up the majority of Unix-like systems out there.
-- Ed Avis ed@membled.com
When I use the filename-completion on Windows (undocumented Registry key called CompletionChar), it always irritates me that it isn't case-sensitive. I go to a directory containing rezoink.c and README, type 'edit r', and it completes to README. Dammit, if I wanted a capital R, I would have typed a capital R!
It just shows that this is a matter of individual taste, and of course it should be programmable so you can choose the style you prefer.
-- Ed Avis ed@membled.com
Does that mean that:
rm **has much more disastorous consequences than I would normally expect?
-"Zow"
bash does do case-insensitive completion, at least in version 2.03 - just put 'set completion-ignore-case on' into ~/.inputrc. It's documented in the man page.
This also works on Cygwin on Windows NT, by the way, which is by far the nicest command line environment I've used on NT.
Particularly if you have to do things on a variety of different Unix boxes, managed by various organisations, you don't usually have the luxury of choosing your own shell.
Although I use bash at home, I'm trying to restrict myself to the intersection of bash, tcsh and ksh, one of which is present on most Unix/Linux boxes these days. Not pleasant, particularly since Solaris ksh doesn't support arrow keys, but better than having to use completely different key bindings everywhere. Bash deserves some credit for emulating most of the csh !$ type features.
The nicest shell I ever used was called msh, which completed whole lines from the command line history, then individual words, then files/directories, all using TAB. zsh and co can probably do this by now, I used msh back in the mid-Eighties.
I was amazed to find out that ksh on Solaris 2.6 at least doesn't support {}-based globbing. I think this is ksh88, but I would hope that more recent ksh'es have this feature.
Green toungues do that to you. Just be happy he's typing drunk and not driving drunk.
If tits were wings it'd be flying around.
Although this is clearly a troll, I'll respond anyway, since I know you trolls hate serious responses because they show you screwed up and wrote a serious question.
RedHat's manual is chock full of instructions that include things for you to type at a shell prompt, and it comes with thousands of executables that aren't tied to anything in the GUI. Admittedly, you could access most of those by creating icons, but that's not so hot for the ones that require varying command line parameters.
So RedHat may be intended to minimize shell usage for everyday tasks, but it's neither intended nor suitable for completely ignoring the shells.
-
It doesn't. If you write a script, and test it with #!/bin/sh where sh == bash, without taking special care to limit yourself to standard sh, don't expect it to work with other /bin/sh's. You'll end up with a script that only works with bash in sh comatability mode. In that case you're better off just using #!/bin/bash (or whatever shell you use), so whoever installs your script knows what shell they actually need.
I would say write for whatever shell you want. Bash is a good bet, as it's available on all linux systems (but be careful; you might inherit an old box with only bash-1!). Zsh is not nearly as common, but it is trivial to install, and has some really nice conveniences to make it worth the effort.
Here's another one: short-form loops...
for i (*) { echo $i }
Useless example, but you get the idea.
Blech. I find "{ ... }" much nicer than "do ...; done". Besides, if you've got more than one command to do, you have to type "do { ... }; done". In that case, why not drop the do/done and just use the braces?
Do/done bothers me, because all of the other languages I write code in just use the braces without superfluous do/done keywords (okay, maybe the occasional "do").
Znork wrote:
:). Which shell has the most features? Not that you'd ever use them all...
Just check the comp.sys.shells faq
Perhaps you meant the comp.unix.shell FAQ? Good pointer. The one with the feature list you are referring to is right here:
UNIX shell differences and how to change your shell
Definitely worth a read. And a specific FAQ on ZSH:
Z-shell (zsh) Frequently-Asked Questions
Of course, I have a vested interested in seeing people switch to zsh. It is my primary shell, and the more people use it, the more boxes will come standard with zsh, and the less frequently I'll have to revert to bash.
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 {} \;
-segfault
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.
:). Which shell has the most features? Not that you'd ever use them all...
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
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.
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) 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.
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/
All that spell-checking and completion stuff has been available in tcsh. Except for *csh basically sucking for shell scripts (aren't most scripts in ksh/bash style syntax?), tcsh does fine for my needs. After all, scripts are supposed to have that first-line program declarator, so ksh/bash scripts still run fine under tcsh.
It's 10 PM. Do you know if you're un-American?
10) precmd() calls commands before displaying the prompt .zlogout ;-)
9) user binding of keys for command line editing
8)
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 are stuck on the "picture is worth a 1000 words" meme. It's not necessarily true. This is why people manipulate spoken and written text rather than using pictures all the time. Each has their place.
It's very hard to automate repeated actions in a GUI, but easy to say "do this action 1000 times with this variation" on a command line.
--LP
The article started talking in ambiguous way about certain conveniences (such as "!!") without clearly saying whether or not they were unique to zsh. ("!!" is available in many shells.) Then it went on to talk about various types of tab completion, some of which at least used to be unique to zsh. (I'm not sure if tcsh or ksh have copied them all yet.) When I first used zsh 7 years ago, it basically mimicked and combined all the best ideas from other shells and added quite a few new ones (Rprompt mentioned in the article was new i think, and nice things like ** recursive directory expansion which wasn't mentioned, etc.) Since then, other shells have copied some ideas back. I'm not really sure where it all stands now, and you are correct, that article didn't really address that point.
--LP
zsh: command- and filename completion are fully programmable. It is 100% equivalent to tcsh for interactive convenience (i.e. better than bash), plus 99.9% /bin/ksh compatible. tcsh is not /bin/ksh compatible at all and thus no good for scripting, and bash is quite compatible but by far not enough to write really portable shell scripts (portable to standard Unix that rely on /bin/sh or /bin/ksh).
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.
but this is a bigger trend, isn't it? all the *sh Unix shells are basicaly retreads and mods of the bourne shell (even csh was written with it in mind), without fixing the fundamental problems. i think this is quite similar to the ever-increasing number of Linux distributions basicaly being retreads of Unix, but again without fixing any of the fundamental problems. rc, as you pointed out, was written for plan 9, a system written from the ground up, keeping what's good in Unix, but fixing the fundamental problems. when you ask:you could just as well s/zsh and bash/Linux and Unix/ and be asking about plan 9. well, if nothing else, it means i don't have to use crap. it provides positive alternatives. some people need crutches. some people think X is as good as window systems get. some people don't see problems with ttys and ioctls. and, sad as it is, some people like having command completion in their shells, or command history, or two (!) editors (good lord when will it end...). i've seen shells with half of
i speak for myself and those who like what i say.
Except that most linux types call /bin/sh are really for /bin/bash :) Oh well.
Die-hards? I think you'd have to be nuts to use linuxconf as anything but training wheels. Anyhow, you can change your login shell with chsh(1). That works for everyone, not just root.
That aside, I thought the article was pretty good. Yes, it attributed many things to zsh which are already present in bash, but articles on interactive shell use are cool - the modern shells are awesomely deep and powerful.
It's hardly OS's fault if you've lost your interest in learning new things.
:D) that doesn't involve the console, then it's much much faster and easier.
It's not really a matter of learning, but a matter of remembering commands, switches, config file paths etc. It's all well and good if you are used to it and do it all the time (like a sysadmin), and can be very very productive. But if you only need to do shell-optimised (which are mainly administrative) tasks very occasionally, then it's a pain having to remember a whole lot of junk that you hardly ever use. With other interfaces like webmin, GUIs etc. all the options are presented to you, so you can just drill down through menus etc. to find what you want. Probably slower than the console for a hardened console user, but for someone who does other work (productive work
This problem was a lot worse when there were versions of *nix that didn't recognize the #! protocol at the start of shell scripts.
The compatibility problems between c and non-c shells was enough that I just gave up on 'c's. That having been said, the one thing I miss the most (I rarely used filename completion) was the {a,b,c} filename expansion construct. It was kinda nice being able to generate 20 filenames with X{a,b,c,d}{1,2,3,4,5}. It's about the only thing in the c shells that I'll skip out of ksh to play with from time to time.
--
Free Software: Like love, it grows best when given away.
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.
--
--
I like to watch.
That's probably why it's not documented otherwise it would probably be a settable option (like command history)
Rich
Even with just one completion rule, specifically "complete cd p/1/d/", when there's only one directory that begins with "a" among dozens of files starting with "a", typing cd a is damn nice. After having this for years, it's hard to imagine using a shell without it.
Do any of the shells other than tcsh have programmable completion? It really is a killer feature that is hard to give up.
PJRC: Electronic Projects, 8051 Microcontroller Tools
There is absolutely no reason why perl or python or ruby or some real programming language shouldn't also be the langauge you use interactively.
Have you tried using any of the "user friendly" distributions? You certainly don't have to use a shell with, say, RedHat. Yes, I know that's ultra-lame, but that's the way it's designed -- to give you everything you need, without having to "resort" to a shell.
Developerworks is an IBM sponsored site, but the information is for non-IBMers, by IBMers and non-IBMers alike. The content creators don't have to be IBM employees.
In fact, I'm working on an article for dW now...
A host is a host from coast to coast, but no one uses a host that's close
Come on you cannot deny that it owns! (prepares to get modded down =)