On 09/07/06, Nadav Har'El <[EMAIL PROTECTED]> wrote:
The original "Bourne Shell" was released in 1977, almost 30 years ago. I am not aware of any "standard" bourne shell other than this antique.
The question is, why limit yourself to teaching a 30 year old fossil?
Again - there are two goals I see which were inter-mixed in the OP - 1. Scriptability - for this I think that learning what a standard "Bourne Shell" will accept is an important step towards writing portable scripts (or just being able to move from one environment to another, e.g. from Debian Sid to Solaris 8). 2. Interactive use - use whatever you like.
When I learned Unix 21 years ago (in 1985), Bourne Shell was already long in the tooth, and better shells like Korn Shell (ksh) already existed.
I started with csh in '86 and switched to HUJI-brewed tcsh as soon as it became available. I'm pretty sure that csh was invented in order to cater for the interactive part of the equation and wasn't quite meant to be used for scripting.
It is worth knowing which shell features are specific to a certain shell and which are the original bash, e.g., for writing portable shell scripts,
See? You seem to have it mixed up already :) You meant "the original Bourne shell" didn't you?
but I think it's important to teach some of the ksh/bash/zsh features that were missing in the original Bourne Shell, including functions, aliases, job control, history, completion, and so on.
job control, history, completion and so on are only relevant for interactive use - for this by all means teach away. Just make sure that people are aware that they should be prepared to live without them when scripting or even using on some systems.
Note that learning shell syntax is a far-cry from being able to write portable shell scripts. A far more difficult issue is compatibility issues with the external commands you need to run. Should you write 'echo -n hello' or 'echo "hello\c"'? Is a certain command available for use? Which command flags are GNU extensions and will not be found on traditional Unix systems?
Read the Wikipedia link I sent in my first response - the Bourne shell was enhanced a bit since it was first introduced (for a start - it was converted from assembly to B then to C :). Also the echo command is supposed to be a built in command with syntax defined as part of the shell's standard syntax. As for this not being enough to be portable - I think that just enforces my argument - if you have to deal with a heterogeneous environment then sticking to "good-ol' Bourne shell" should help you reduce the amount of variables you have to deal with.
Please also note that a quick Googling shows that POSIX chose as its standard shell the Korn shell, and NOT the Bourne shell. Check out for example http://docs.hp.com/en/B2355-90046/ch15s03.html,
This page says that the POSIX shell is based on the Korn shell syntax - if you want to be practical and use the most widely available shell then I still think that the Bourne shell wins. See http://docs.hp.com/en/B2355-90046/ch01s01.html#d0e116 (under "What is Bourne Shell").
A standard is needed, yes. But the 30 year old Bourne shell is too old...
It's not that old. It was updated since its first introduction.
By the way, don't forget that many people switched from Bourne Shell to Tcsh because they wanted the interactive features. It's important to show them that they can get the both of these worlds: with ksh, bash or zsh, they can have all of Bourne shell's and Tcsh's advantages, and then some.
Again - for interactive use go ahead and use other stuff - you'll get an error and correct your syntax in the next command you type. But when writing a script which you won't "be there" when it fails I'd recommend sticking to the most basic standard you can rely on. --Amos -- "(a grizzly) can tear through a tree like a Jewish mother through self-esteem." - The Simpsons ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
