[96531] in RedHat Linux List

home help back first fref pref prev next nref lref last post

Re: BASH scripting question

daemon@ATHENA.MIT.EDU (Cameron Simpson)
Tue Oct 27 19:15:44 1998

Date: Wed, 28 Oct 1998 11:11:29 +1100 (EST)
X-Original-To: redhat-list@redhat.com
From: Cameron Simpson <cs@zip.com.au>
Reply-to: cs@zip.com.au
To: redhat-list@redhat.com
Resent-From: redhat-list@redhat.com

On 28 Oct 1998, in message <36364C2C.87EBED0D@wwnet.net>
  Ted Maciag <tsm@wwnet.net> wrote:
| I agree, with a twist.
| Korn is great and can be loaded every where you want it to be.  Good Luck!
| -ted
| 
| John H Darrah wrote:
| > On Tue, 27 Oct 1998, Cameron Simpson wrote:
| > > On 24 Oct 1998, in message <Pine.LNX.4.05.9810231409110.5138-100000@mallard.itep.ru>
| > > Alexei Nefediev <nefediev@heron.itep.ru> wrote:
| > > > what should I do to learn my own script to
| > > > understand switches and to report about its
| > > > usage when started without arguments?
| > >
| > > Step 1: Never write for "bash" (or the other
| > >         dialects like zsh ksh etc) if you can
| > >         write for plain vanilla Bourne shell (sh).
| >
| > WRONG!!  This is just another one of these
| > religious statements that confuse many newcomers.

I sometimes think people can't read.

The various flavours of shell are all very nice (we'll leave csh out of this,
of course:-) but when writing code, it is bad practice to _needlessly_ use
less portable features. Did I say "never use bash"? No. I said never write
for a dialect if you don't need to.

And it's especially bad to require a particular dialect (eg bash) if you're
_not_ using something only it provides.

_All_ unix systems have a /bin/sh. These days you can expect it to have
shell functions; on most systems, thanks to POSIX, you can expect it
to have ksh features. On Linux, /bin/sh is a bash.

If, without being greatly inconvenienced, you can write code that runs on
a common subset of these (i.e. SysV sh level for great portability and ksh
level for pretty good portability) then your script can have a #!/bin/sh
up the front and you can give it to _anyone_ and it'll "just work".
Depend on the extensions and that's less the case.

Saying things like "Korn is great and can be loaded every where you
want it to be" is a tad trite. On your home system, sure. At work? Only
if you're the sysadmin or the sysadmins there are friendly. On your
ISP's shell account machine? Even less likely.

In any language (shell, perl, C, whatever) is it better to use the common
subset than some spiffy extension unless there's specific, strong, benefit.
That way you can take your code to someone else's system and have it work.

By all means use the extensions when they're apt (for example, greatly
increasing performance or significantly increasing the program's
readability or succinctness). But in a heterogeneous world, and
especially one where you lack sysadmin rights everywhere, you're making
trouble for yourself. Always ask yourself how much that future trouble
is worth against the convenience of the moment.

In short, portable conservative code is well worth minor inconvenience.  So
if it's easy, do it portably. If it's hard, _then_ go for the tool with more
doohicks on it, but bear in mind that there are places you may not have that
tool to hand.
--
Cameron Simpson, DoD#743        cs@zip.com.au        http://www.zip.com.au/~cs/

Chris Gascoyne, while struggling to program stuff on Microsoft Windows:
"I thought people said how bad it was just because they didn't like Microsoft."


-- 
  PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
		http://www.redhat.com http://archive.redhat.com
         To unsubscribe: mail redhat-list-request@redhat.com with 
                       "unsubscribe" as the Subject.


home help back first fref pref prev next nref lref last post