Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

To Z Or Not To Z 148

Posted by Hemos from the that-is-the-question dept.
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."
This discussion has been archived. No new comments can be posted.

To Z Or Not To Z More

To Z Or Not To Z

Comments Filter:

  • "Csh Programming Considered Harmful" (Score:1)

    by Anonymous Coward
    Go type the subject line at google.

    csh and its derivatives are just fundamentally broken. I tried it back in 1985 and quickly grew to hate it.

    Let the damn thing die already.

  • Bah (Score:2)

    by Anonymous Coward
    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!

  • Re:Zsh advocacy (Score:2)

    by Anonymous Coward
    Yes, this article barely scratched the surface. The new compinit completion continues to blow me away with the breadth of things zsh can complete on out of the box -- about 260 different programs have special hand-crafted completion by my count. It's a shame the article glosses over it. Some of my favorites:

    • For make it parses the makefile and completes available targets and make variables.
    • For cvs, it can tell if you're adding a file, working with an existing file, or whatever, and the completion adapts to suit. "cvs add " will complete to any files that arn't in the repository yet, and so on.
    • On a debian system, there is extensive completion for apt, dpkg, and even the bug reporting tools. It knows if you're telling apt to install a new package, if so it'll complete to the names of all available packages. If you're telling apt or dpkg to remove a package, only those packages that are currently installed are completed. Very powerful.
    • perl -M completion.

    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 is a dog. Whilst it's got some nice features, it still uses all that godawfull csh syntax. Try zsh, get a real shell syntax (that lets you type a for loop on one line).

    -Dom
  • precmd() is nice, but unfortunately, it doesn't allow you to modify the command before zsh actually executes it. It might not be precmd(), but a similiar function, I can't remember. But it's very annoying because it lets you write a function that takes URL on the command line, but then you get an error after you've processed it.

    -Dom
  • There's a damned good reason why it shouldn't be used interactively, and it's the same one that means you wouldn't want a COBOL shell. There's just too much syntax. It gets in the way of typing in commands quickly and efficiently.

    A shell has different requirements to a programming language, don't get them confused (even though they cross over a little bit).

    -Dom
  • Tcsh, the Tenex C shell

    I thought the t was for tectronix.
  • ive noticed that many irix (SGI) users dont touch the command line. of course this is in situations where there is a sys admin to take care of those things so all they are doing is playing with the file manager and thier apps (netscape, maya, etc)
  • 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.
  • I've often thought that tclsh could be a decent shell with some interactive features added. Tcl seems to match the semantics that shells require quite nicely -- everything is a string, etc. The quoting rules are more sane than shells usually are. But Tcl seems to be sorely missing some way to expand a list into arguments, which would be important with globbing and such.

    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.

  • Well, I don't know if MS documents this feature, but even though it's kinda nice, it's also broken (as compared to UNIX-type completion). The completion in DOS will always complete, that is, even when there are multiple matches it just completes one for you.
  • Since you seem to know a few things about this programmable filename completion thing... Is it possible for the shell to work around the brain-dead file naming rules of Unix, so that if I type 'cat r' it will fill with README, and not complain about no file with first letter 'r' is found? This single feature is incredibly useful for people who just wants to work instead of wrestling with the OS.

  • Re:yuck (Score:2)

    by Tet ( 2721 )
    starter question for 3 points: what does $@ do in the bourne shell? why is it there?

    It expands to all the argument passed to the current program or function, just with different quoting semantics to $*. Your point being?

  • Last time I checked, Visual C++ is case-sensitive for the variable names. Gee, even C# is. I dunno about VB, though.

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

  • You are talking about the ISO-8859-1 subset, not Unicode.

    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.

  • Next time you use a filename to start a sentence, please tell me. And I was unaware that you could not use a proper noun to name a file.

    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.

  • Actually nobody in their right mind uses those.

    All of these shells have been ported to NT, so in fact you get exactly the same question there as well.

  • Actually, no. This form of file completion (show then entire first match) is what was first done by the csh shells. They used ESC to trigger filename completion (due to lameness in the Unix tty drivers this was the only sequence detectable).

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

  • Actually Unix is "case-preserving", you mean case-independent plus case-preserving. This is probably the most common system, even some Unix systems (AFS) follow this model, too.

    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!
  • Well you finally said what I have been trying to get through the thick skulls of the NT defenders: "If you want to argue about where the case-matching should be implemented". That is precisely what I am trying to argue.

    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.

  • This is not a speech. I like zsh, mostly because it's the shell I started out with back in 93. Now I mostly use bash since I've grown used to it from working with linux some 5 years but still I think that zsh hold a couple of points on bash. One of the stronger points I'd say is that it's shipped in larger OS'es like Solaris and AIX and bash is a download, install, fiddle, pray that it works. Still I don't think there's any problem with the type of shell you are using but instead you tend to get a problem when you access them from other systems (microsoft and apple) with say a telnet or ssh client. You tend to ask yourself why the characterset never works, why you have to remap backspace and delete, why the colours aren't supported and worst of all. Why it changes from program to program. It's easy to use a shell, so why have a flamewar over wich is best when we can put our energy into bothering microsoft into putting a telnet client worthy of the name in the Windows OS. // yendor
    --
    It could be coffe.... or it could just be some warm brown liquid containing lots of caffeen.
  • 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.
  • 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.

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

  • Re:Hi (Score:2)

    by PD ( 9577 )
    Green toungues do that to you. Just be happy he's typing drunk and not driving drunk.
  • false, i do 8bit input all day,
    in french. filename command etc...
  • 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.

    -

  • and I don't know if it removes features that are strictly a superset of sh's features,

    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.

  • for i in *; do echo $i; done
    Seems pretty much as short.

    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").

  • prepare to zsh
    move zsh
    somebody set up us the bash.
    move zsh
    zsh
  • Znork wrote:

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

    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 [landfield.com]

    Definitely worth a read. And a specific FAQ on ZSH:

    Z-shell (zsh) Frequently-Asked Questions [landfield.com]

    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.
  • mutende:~$ echo $0
    /bin/bash
    mutende:~$ echo X{a,b,c,d}{1,2,3,4,5}
    Xa1 Xa2 Xa3 Xa4 Xa5 Xb1 Xb2 Xb3 Xb4 Xb5 Xc1 Xc2 Xc3 Xc4 Xc5 Xd1 Xd2 Xd3 Xd4 Xd5
    mutende:~$
    --
  • he probably posted this after last call

    Pope

    Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
  • Uhh.. you can do the same with bash:
    e.g.

    $ pwd
    /home/slams
    $ CDPATH=.:$HOME:/usr/local:/usr/local/www
    $ cd bin
    /usr/local/bin
    $

    (assume there isn't a bin/ in either . or $HOME)

  • I agree, Cygwin on NT/2K is wonderful. Of course, I switched to using zsh.

    - Brian
  • I absolutely despise this attitude. `Intersection of bash, tcsh and ksh', my arse! Learn each of them for what they're worth and then you'll have grounds to hold an opinion. Anything else is "it might not work in this shell so I won't bother". Well breathing underwater might not work either, but you're welcome to try.
    ~Tim
    --
    .|` Clouds cross the black moonlight,
  • may be z answer Just sounds stupid in the UK.

    As well as Canada, Australia, Ireland, and practically anywhere else except the US. I remember occasionally the Canadian distributors for US corporations are too lazy to repair the "English" on product packaging, and we end up with products like E-Z wipes.

    I won't even mention the quality of the mandatory French translations we see. Actually, one example is worth citing:

    Occaisionally we see the phrase "No preservatives" translated to "Sans preservatifs" on food packaging. The actual translation should be "Sans agents de conservation", which wouldn't be so funny except for the fact that "Sans preservatifs" translates to "No Condoms Inside".

    Brilliant.
  • Perhaps it's not just the Americans' English that needs repairing. It seems I should have used the preview button:

    I remember occasionally the Canadian

    and of course, later on:

    Occaisionally

    It's still early...
  • 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 {} \;
  • You are not worthy of Linux. Return to Redmond.
  • Yes, and they realise, for instance that in English (and most European languages), a pen is still a pen, even if its at the start of a sentence, and is therefore spelt `Pen

    OTOH, most european languages need also non-ascii characters, and saying "À is the capitalized version of à" is something that you can do only if you know what encoding has been used for the name of the file, and then we are still ignoring names in nonalphabetical languages with variable length encodings. Since some system calls require the name of a file as a parameter, this knowledge should be built in the kernel, with all the bloat it requires.

    As you see, this is the sort of thing that better lives in userspace.

  • On the other hand, a UNICODE character is twice as large as an 8-bit one, so it does increase the code size somewhat

    This is why UTF-8 exists and is used on most unices, and why I consider it a better solution than plain (untrasformed) UNICODE (or UCS-16, if you like).

    See this page [cam.ac.uk] for further reference.

  • Ah, of course you're right, thats the one I meant. Very good links for deciding which shell to use.

  • Re:Shells in a Nutshell (Score:3)

    by Znork ( 31774 ) on Sunday March 18, 2001 @02:42AM (#356453)
    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.
  • Here's a setup example for your prompt on your windows 2000 box.

    red='%{\033[31m%}'
    grn='%{\033[32m%}'
    yel='%{\033[33m%}'
    cyn='%{\033[36m%}'
    whi='%{\033[37m%}'

    prmtWinTitle='%{\033]0;%D{%Y%m%d-%H%M%S%a} %~\007%}'
    prmtDate="${grn}%D{%m%d%a}-${grn}%D{%H:%M:%S}"
    prmtHistNum="${cyn}%2!"
    prmtHost="${whi}%m" # just in case you want to add it.

    prmtLft="${prmtHistNum}%(!.#.>) "
    prmtRgt="${yel}%60<...<%~ ${prmtDate} ${whi}%?"

    PROMPT=$(echo "${prmtWinTitle}${prmtLft}${whi}")
    RPROMPT=$(echo "${prmtRgt}${whi}")
    unset red grn yel cyn whi
    unset prmtWinTitle prmtDate prmtHistNum prmtHost prmtLft prmtRgt

    ---
    I'm still looking Zelda 2 disc version for the Famicom.
  • xterm*)

    ct=$(xprop -id $WINDOWID | grep WM_NAME | cut -d=-f2 | tr -d \")
    precmd() { print -Pn "\e]0;$ct - %~\a"}
    prexec() { print -Pn "\e]0;$* - %~\a" }
    ;;

    esac

    When I use X, my xterms will display the name of my xterm, concatenated with my present working directory. When I execute a command, this command will now be in my xterm title, concatenated with the present working directory.
    I do not know of an equivalent to preexec() in bash.
  • No. That would do the same thing as "rm *". This is because "**" only has expanded meaning in path elements, not in the final name element. Thus, you'd have to type "rm **/*" to get the '**'s expanded meaning to be significantly more destructive. Also, typing "rm **/" would try to remove all the directories in this dir and all subdirs, but that would fail (due to rm's inability to remove subdirs).
  • Let's see bash do this:

    zsh% echo x{1..20}.txt
    x1.txt x2.txt x3.txt x4.txt x5.txt x6.txt x7.txt x8.txt x9.txt x10.txt x11.txt x12.txt x13.txt x14.txt x15.txt x16.txt x17.txt x18.txt x19.txt x20.txt
  • Zsh has the most powerful programmable completion I've seen. Yes, cd completes only directory names (and you can even type something like "cd /u/X/b/" and have it expand to "/usr/X11/bin/" with one TAB press).

    Even better, the latest zsh has completion support for commands that output help text via "--help". This allows it to automatically query the program for the command-line options and to complete them, including giving you the help-text. For example:

    zsh% diff --i<TAB>
    --ignore-all-space -- ignore all white space
    --ignore-blank-lines -- ignore lines that are all blank
    --ignore-case -- case insensitive
    --ignore-matching-lines -- ignore lines that match regex
    --ignore-space-change -- ignore changes in the amount of white space
    --initial-tab -- prepend a tab

    Other completion areas include fabulous support for CVS (e.g. "cvs commit <TAB>" completes only files that need to be commited), completion of installed RPM package names, completing job numbers that belong to the current user, and that just barely scratches the surface.

  • Re:z's (Score:1)

    by Phong ( 38038 )
    If you pronounce 'Z' as "Zed" instead of "Zee", then how in the world do you make the "ABCs Song" rhyme? "...cue are ess, tee you vee, dubba-you ex, why and zed" just doesn't seem to cut it.

  • Zsh advocacy (Score:5)

    by oops ( 41598 ) on Sunday March 18, 2001 @04:22AM (#356460) Homepage
    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.

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

    You're right; completion of words and lines from history are possibly the single most useful features any shell can have. There are different techniques available:

    • Completing lines from history, incrementally. bash and zsh have this (C-r)
    • completing lines from history based on a prefix (by default bound to M-p in tcsh/zsh, unbound in bash).
    • completing words from history. tcsh and zsh have this bound to M-/ by default. bash2 has it bound to M-TAB. bash1 doesn't have it at all.
    • As a special case of the last one, M-_ (meta underscore) is bound by default in bash, tcsh and zsh to reinserting the last word of the last line. This is equivalent to the !$ history expansion, but it's nicer, because you see what you're getting before you hit enter.

    Much as I'm a zsh zealot, knowledge of these and a few other essential key-bindings will get you more immediate benefit out of your shell than learning a new shell. I wrote a page on this:

    http://adamspiers.org/computing/shells/

    That said, if you already know these shortcuts well and you're thirsty for more speed and power, try out zsh's new completion system...

  • Not only that, but zsh can optionally watch
    out for rm * command-lines and make sure you
    really want to do that before doing it.
  • I tried zsh a while back looking for a restricted mode shell. Although the documentation said it had this feature I could not get it to work. I ended up using bash shell restricted mode.

    zsh -r

    That wasn't hard, was it?

  • Everyone missed zsh's best bits! (Score:4)

    by adamspiers ( 45617 ) <adam.spiers@net> on Sunday March 18, 2001 @04:36PM (#356464) Homepage
    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/

  • despite being smaller and simpler, it's more powerful. it provides branching pipelines for example:

    % cmp <{echo hello world} <{echo hello Xorld}
    /fd/6 /fd/5 differ: char 7

    you are so right...that is so much more powerful than this:

    zsh% cmp <(echo hello world) <(echo hello Xorld)
    /proc/self/fd/11 /proc/self/fd/12 differ: char 7, line 1

    Next time, at least look at the shell before dismissing it. I gave that courtesy to rc when it came out. I've been using zsh for over 10 years (way back when Paul Falstad was still at UPenn working on it). I've used the other shells, but I just like the feature set of zsh better.

    But honestly, the best shell ever was the adventure shell. ;-)

    (wish I still had a copy...especially with April Fools coming up. ;-)

    IMHO,
    Michael
  • 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.

  • Top 10 reasons for usung Z-Shell (Score:4)

    by kune ( 63504 ) on Sunday March 18, 2001 @05:41AM (#356467)
    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 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
  • What's the difference between .zlogout and .bash_logout in bash or .logout in tcsh (and csh, and everything else as far as I know)?
  • Tektronix isn't related to shells at all. AFAIR, it was a protocol for sending images over a telnet connection. It's also a provider of equipment for communication networks.

    Tenex was an operating system developed by BBN and used on most systems on the ARPANET by the early 1970s. It was the predecesor of DEC's TOPS-20 (also called TWENEX).

    Both Tenex and TOPS-20 had programmable command completion and other features that impressed the creator of tcsh, and the rest is history.

    Sources: tcsh(1), the TWENEX entry in the Jargon File, and Tektronix.com
    --
  • because hey seems to beer how to know coherent pozsht... HEEK!
    --
  • 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).

  • You Post this at 2:47AM... (Score:5)

    by PhatKat ( 78180 ) on Sunday March 18, 2001 @01:13AM (#356474) Homepage
    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.
  • i love rc. i use it on plan 9 all the time. it's my default shell on all my Unix boxes. i've even gone so far as to re-write a number of my Unix (solaris) administrative scripts into it. for programing, i find it far better than any other shell i've seen, and the fact that it's so much smaller is a huge win, too (although fewer and fewer people seem to really care about code bloat, unless it means we can point fingers at Micro$oft).
    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:
    ...what's the point, if monstrosities like zsh and bash continue to exist?
    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 /bin built in, or screen, or various mouse-aware thingies. people are trying to compensate for the fundamental problems that none of their systems will address. i used to demand a searchable command history in my shell - once moving to rc and rio (the plan 9 window system), i've never missed it.
  • 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!

    Except that most linux types call /bin/sh are really for /bin/bash :) Oh well.

  • Erm, no.

    I know for sure Scotty uses the z-shell.
  • Yeah, I almost said that, but the original author didn't specify what tool he'd use to edit /etc/passwd, so I thought I should give him the benefit of the doubt.
  • From the article:
    If you are convinced by Zsh, you can make it your default shell through the "User accounts" panel of Linuxconf (or for the die-hards amongst you, by editing /etc/passwd).

    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.

    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 :D) that doesn't involve the console, then it's much much faster and easier.
  • The evil aspect of *csh for me is that it's just close enough to something like bash to confuse you into thinking you're using the real thing. Unfortunately, the programming constructs are quite different, so you have to remember all the time whether the shell you're working in/programming is 'c' type.

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

  • ...in zsh actually rips off a windows idea, if you can believe it. if you turn on tab completion in windows (see below) using tab will auto-complete with the first matching candidate, while tab will cycle forward through matching results, and shift-tab will cycle backwards. i wish there was a way to make it stop for more info like bash or tcsh though. but i guess it's better than nothing. at least zsh shows you the list that you're cycling through.

    tab completion in windows (cmd.exe)

    • run regedt32
    • open reg key HKEY_CURRENT_USER -> Software -> Microsoft -> Command Processor
    • change the CompletionChar key to 9 (in hex or decimal)
    • close regedt32, and open a new shell. voila: tab completion.
  • Yum... there's nothing like eating cold and salty fish for your hangover hunger.
    I'm told that Malda chants that over and over in his head while he goes down on Sarcasta.

    --

  • Normal Windows users, you mean. I hack in C-family languages on UNIX, and case-insensitivity isn't "normal" to me at all. Maybe you're confused, and think you're reading ZDnet or something?

    In fact, the only UNIX application I can think of which is purposely case-insenstive in some areas is GNU Emacs, with regards to the default incremental search and DIRED filename-completion.

    --

  • There is no DOS prompt in W2K, the command prompt may look like DOS, but it ain't DOS.
    Well, there is, actually. I've played around with the NT5 boxes at work and discovered that there are two xterm-ish programs in NT5. If you run "cmd", you get an NT5 command window. If you run "command", you get a "Microsoft Windows DOS" command window. Interesting.

    And in my quest to give an old NT4 box a usable console, I discovered (via Google) a registry hack to give NT4 command-line completion.

    My main use for these boxes is telnet. I've also noticed that in NT5, the telnet client is more integrated; in NT4, typing "telnet" opens a new window, which is endlessly annoying. The ability in NT5 to run telnet in a command window means that I can run telnet full-screen -- and almost pretend I'm using a real computer. :-)

    --

  • Shells in a Nutshell (Score:3)

    by The_Messenger ( 110966 ) on Sunday March 18, 2001 @01:54AM (#356487) Homepage Journal
    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.

    --

  • It also crashes from time to time, taking the DOS window with it.

    That's probably why it's not documented otherwise it would probably be a settable option (like command history)

    Rich

  • finally, some zsh coverage. everyone thinks i'm nuts, but i'm a zsh/joe/elm user. its nice to hear about zsh. now, anybody else out there use joe and/or elm?
  • ZSH! Read the article!!!
  • Agreed. Programmable (TAB) completion is really a killer feature. I suspect it's not widely known because it doesn't come set up out-of-the-box on some major distributions, like redhat (or at least the 6.x versions I've tried).

    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.

  • Just to jump on the bandwagon, my favorite feature is that zsh will expand wildcards entered on the command line.
    So you can type ``rm -rf *'', then hit <Tab>, and go back and delete that one thing you want to leave.
  • I used to religiously use tcsh, as well, because of it's very nice interactive feature set. But I always hated having to write my short little interactive scripts in csh syntax. And sometimes I was unable to do things (although tcsh is a little better than csh in that regard). I refused to use bash because of its vast incompatibilities with not just ksh, but even plain Bourne shell. Not to mention some interactive annoyances (My favorite example -- If I want to get a listing of all the files that match what I've type in so far, I can type Ctrl-D in both tcsh and zsh. In bash, I have to hit Tab twice. And the first one looks for a single matching file, but fails (which I already knew it would) and beeps at me. As if I've done something wrong. Aargh!) Then I found zsh. It truly is Nirvana. You should try switching. You'll have some minor trouble getting your aliases ported over and getting used to using Bourne/Korn syntax, but within a month, you'll love it.
  • Not pleasant, particularly since Solaris ksh doesn't support arrow keys
    Yeah it does. type ``VISUAL=emacs'' and arrow away.

    And if you want portability, stick with only Bourne shell syntax. And definitely throw bash outta there. Then again, this is your interactive life, and you can do what you want.

  • And most of us diehards would tend to use vipw anyway, assuming chsh didn't work (which it doesn't in some annoying environs).
  • You have some really good points here. You're certainly right about quoting issues. It's something that's always been a problem, and in our short-sightedness, we, as Unix users, ignore it implicity. There are other problems, too, as you imply, that we also take for granted. It's nice to see that there are those Plan9 and Inferno folks out there — those that want to take all the Unix loveliness and fix the misfeatures and bugs. Too bad that it'll never catch on ;-( (Not trying to be a bastard here -- just being objective.)

    I also took a closer look at rc and your sh. (Wouldn't a different name have been appropriate?) They have some really powerful features. Especially the file descriptor replacement thing that you exemplify. (zsh-workers! Steal this feature!) (By the way, zsh has a multiple redirection feature, but I'm pretty sure it won't work for stuff like cmp that needs two different inputs. It just concatenates things together into the input file descriptor, like ``cat < file1 < file2''.) But one thing that you miss is that these shells (zsh, bash, tcsh, etc.) are intended (at least in my mind) for interactive use. There's little need for being able to scroll back up in command history if you're programming a script. I find it unlikely that anyone would seriously write big scripts using those shells (although I have written stuff for personal use in zsh because of some nice glob and word modifiers). They use sh, or maybe ksh for something complex, because it's pretty well guaranteed to be portable. rc and your sh would be appropriate as well, if they were as or nearly as ubiquitous as sh and ksh are, whereas zsh, tcsh, and bash are not appropriate for that sort of thing, at least due to their size and related dilatoriness. (Despite this, there are a number of Linux distributions that have any number of scripts written for bash, whereas those who know what they're doing use ash (Almquist's a shell, not adventure shell), which is about as tiny as you can get.) Regardless, for interactive use, those of us with fallible fingers (and brains) want fancy command completion and interactive histories. That's why no one really uses sh or csh interactively anymore. If one added those types of interactive features to those shells, you might just have a couple of hits on your hands.

    And, as a side note, zsh actually implements many (most?) of its features as loadable modules, which I noticed you mentioned as a feature of your sh. So you're not out there toally alone. zsh is still (much) bigger, though.

  • Is it just me, or were most of the features listed in that article just ones that are typical amongst most shells (ie bash, tcsh, etc)? It was almost as if they were suggesting that these features were exclusive to zsh (although it did mention "as with bash" for the command line completion).

    I can't really understand why this appeared on Slashdot, though. I mean: "Most developers and users of Linux come into contact with a UNIX shell sooner or later." ?? Sooner or later? How could anyone use Linux (or any other unix-like os) without coming into contact with a UNIX shell first and foremost?

    The mind boggles.

  • I imagine you'd have to be a bit of a retard to never open an xterm. How could you just turn your back on all of that command line goodness?

  • I don't recall saying that Linux == Unix. In fact, I intentionally called linux a "unix-like os" in order to prevent just this kind of comment.

  • I prefer to use psh, which allows me to do far more than any of the existing shell languages, as it leverages he entire perl programming language.

    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 =)
  • If I want to write a script, I'll do it in whatever language is convenient. Maybe sh, more likely Perl. If I want to use an interactive shell I'll use whichever one I find is more convenient.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close