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."
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.
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 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.
Wansu, th' chinese sailor
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.
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.
"Hot lesbian witches! It's fucking genius!"
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.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
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.
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.
-- 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.
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.
-
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").
prepare to zsh
move zsh
somebody set up us the bash.
move zsh
zsh
comment directly in my journal
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.
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:~$
--
Unselfish actions pay back better
he probably posted this after last call
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
It doesn't mean much now, it's built for the future.
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)
-slams
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 {} \;
-segfault
You are not worthy of Linux. Return to Redmond.
-brain
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.
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 for further reference.
Ah, of course you're right, thats the one I meant. Very good links for deciding which shell to use.
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.
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.
ct=$(xprop -id $WINDOWID | grep WM_NAME | cut -d=-f2 | tr -d \")
;;
esacprecmd() { print -Pn "\e]0;$ct - %~\a"}
prexec() { print -Pn "\e]0;$* - %~\a" }
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.
-Gwizdak.
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
..wayne..
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.
..wayne..
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.
..wayne..
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.
zsh -r
That wasn't hard, was it?
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:
/fd/5 differ: char 7
/proc/self/fd/12 differ: char 7, line 1
;-)
;-)
% cmp <{echo hello world} <{echo hello Xorld}
/fd/6
you are so right...that is so much more powerful than this:
zsh% cmp <(echo hello world) <(echo hello Xorld)
/proc/self/fd/11
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.
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
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
--
--- Sueños del Sur - a webcomic about four young siblings
because hey seems to beer how to know coherent pozsht... HEEK!
--
--- Sueños del Sur - a webcomic about four young siblings
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.
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.
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.
tab completion in windows (cmd.exe)
--
--
I like to watch.
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.
--
--
I like to watch.
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
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!!!
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
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.
Fuck 'im up, Tim! His views are invalid! -Pirate Corp$
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.
Fuck 'im up, Tim! His views are invalid! -Pirate Corp$
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.
zsh is 1337, enough said!
http://get.a.clue.de - RTFM
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.
...is perl of course!! Who needs silly features like "command history" and "home directories"? I'd rather `ls -la` than ls -la. Doesn't everyone?
====
Crudely Drawn Games
In Ireland St Patricks day (/festival week) has been Postponed due to the foot and mouth disease scare in England.
s na ke4.jpg
St Patrick has been driven out by the snakes...
http://images.ireland.com/newspaper/front/0301/
besides, loads of irish people think Guinness is horrible (an aquirred taste).
(-1, Way Offtopic)
Bash & tcsh can do the same things that zsh does. It looks like some replication of work if you ask me.
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
Hmm, let's look at some of my recently edited files:
fft_zr.c
Nope, can't see a 'word' in that.
decss_434.c
Nope, can't see a 'word' in that.
Why the buggerybollocks are you talking about words - we're talking about _filenames_.
FP.
--
Also FatPhil on SoylentNews, id 863
I think it's cool that there is more support, but supporting the Geforce 3 before it's out?
Yeah, I've heard that zsh in 3D mode has a great framerate. The accelerated ANSI color rendering is also supposed to be pretty good, though not as fast as in bash or csh...
The clash of honour calls, to stand when others fall.
Come on you cannot deny that it owns! (prepares to get modded down =)
the moment i read "a superset of all those other shells", i shuddered. "all those other shells" are bourne shell-like, and they are all broken. none of them fix the main problem with the bourne shell: the horrible quoting semantics. this is the main cause of bugs and security flaws in shell scripts around the world. the classic "change IFS and watch everything break" problem.
starter question for 3 points: what does $@ do in the bourne shell? why is it there?
for a small and simple shell that actually fixes some of the fundamental problems with the original bourne shell design, check out rc. it was designed for plan 9, but the above version runs under most versions on UNIX. 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
along similar lines, i wrote a shell for inferno which is even smaller (39K), simpler and more powerful. but what's the point, if monstrosities like zsh and bash continue to exist? :-(
It somewhat defeats the purpose of UNIX componentism to build this sort of functionality into the shell. Your "multiple redirection"
$ ls > foo > bar
can be accomplished in a shell-independent manner like this:
$ ls | tee foo > bar
or the more extreme case
$ ls | tee foo | tee bar | tee baz > quuz
Although I admit it's faster to type when the shell does it.
Learn your standard UNIX tools. They can do much more than you probably assume.
Typing R is your idea of "wrestling with the OS"??
Wow!
I really hate Dan Patrick.
"Command.com or cmd.exe? Hmmm..."
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
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 wacky world of linux installs has changed greatly in the last couple of years. i'm trying to learn linux from a linuxppc install on one of my mac clones, and if i wasn't interested in the lower-level command line work, i could probably get everything i need to done in the gui.
linux has changed from being equivalent to wfw, where dos knowledge was still highly necessary, to being more like win9x, where a novice user just doesn't need the command shell. and note that this is an analogy, not a slam of linux in any way. i really shouldn't have to explain that, but i am not in the mood to brush off zealots today.
--saint----
How did you ever get a banana stuck in your ear? That really boggles my mind.
Funny, I rarely 'resort' to X for any of my admin tasks. I find that the shell commands are still superior in many ways.
I find the zsh somewhat intreguing I must admit. However, I have only seen some minor differences between it and other shells.
LedgerSMB: Open source Accounting/ERP
Command lines are here to stay. Remember Star Trek IV? Scotty didn't know crap about the mouse that McCoy handed him, but he went to town on the keyboard (I know, it was a Mac, whatever). He knew the keyboard because Scotty uses bash shell, baby! Learn it, love it, live it.
"My mother works for Microsoft now. A whole other cult."
CAPTAIN: It's you!!
CATS: How are you gentlemen!!
CATS: All your bash are belong to us.
CATS: You are on the way to enlightenment.
"My mother works for Microsoft now. A whole other cult."
hehe
NOT ZEE
--------------------------------- Born Again Bourne Again Believer: New Life, GNU/Linux Be Free!
... I do hope this doesn't become too popular, otherwise we could have another entrant to the sh/ksh/*csh/bash holy war^H^H^H^H^H^H^H^H bloodbath^H^H^H^H^H^H^H^H^H confusion.
"We are Microsoft. You shall be assimilated. Competition is futile."
krakatoa ~ % echo $0
zsh
krakatoa ~ % 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
may be z answer Just sounds stupid in the UK.
So does To z or not to z
Yes, I am moaning because it confused me this early on a Sunday morning (11am)
@ .
contrary to the popular belief that *csh shells are evil, tcsh absolutely rocks. Show me another shell with extensive programmable command completion like tcsh, and I'll switch tomorrow!
Damn, you are right there. I thought I was the only one having problems entering 8bit stuff into tcsh. I guess it's a feature you pay for, for having such nice command completion.
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.
What I'd like to see in a shell is a configurable restricted mode. So I can allow some users to cd , some to cd out of their homedirectory hierarchary, etc., etc...
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Did you know the Windows 2000 DDK uses command-line build tools? It's true.