Date: Sat, 18 Jul 2009 13:23:56 +0200 From: Paul Schenkeveld <fb-chat@psconsult.nl> To: freebsd-chat@freebsd.org, chat@freebsd.org Cc: Brett Glass <brett@lariat.net> Subject: Re: Bourne shell short-circuit operators improperly documented Message-ID: <20090718112355.GA99793@psconsult.nl> In-Reply-To: <20090718024835.GB8379@steerpike.hanley.stade.co.uk> References: <200907172257.QAA15292@lariat.net> <20090718000116.GA8379@steerpike.hanley.stade.co.uk> <200907180121.TAA16416@lariat.net> <20090718024835.GB8379@steerpike.hanley.stade.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 18, 2009 at 03:48:35AM +0100, Adrian Wontroba wrote:
> > No wonder I don't use short circuit operators much. When zero
> > equals one, it gets rather confusing.
>
> I agree that they can be confusing. Forget the 0 and 1, just think of
> success and failure.
>
> > It's also confusing that they are called "AND" and "OR" operators
>
> I agree with that too. As Jeremy wrote, "conditional execution" would
> have been a better description.
Their naming and meaning are completely in line with the semantics of
the if, while and until operators of sh. For example:
if newfs /dev/da0 && mount /dev/da0 /mnt && mkdir /mnt/some_dir
then
cp this_file /mnt/some_dir
chown 123:456 /mnt/some_dir
chmod u=rw,go=r /mnt/some_dir
echo "Installed this_file in /mnt/some_dir"
fi
Meaning: *IF* I can newfs my usb stick *AND* I can mount it on /mnt
*AND* making a subdirectory on it succeeds *THEN* copy this_file into
that directory and so on.
Remind that if, while and until, although often followed by the [
synonym of the test(1) command, the original intent of them is that
they can be followed by any command and operatoe on the success/failure
condition of that command.
Choosing 0 for true and non-zero for false is also a very natural
choice. There is only one way the command can succeed and many ways
the command can fail. So if you have to choose one value from the
range 0 through 255 to use for success I'd go for 42^W 0 of course!
> > (and look like the short-circuit AND and OR operators in other
> > languages, which all do what you would expect).
>
> Well, they are operators and there are only a limited number of special
> characters available. Look at all the different uses of & and | in the
> shell (8-(
>
> Perhaps the syntax could have been " and " / " or " (as in Perl's
> and / or statement qualifiers (something() or die "oops";), but it is
> far too late to change sh syntax. We have to live with it or use a
> different shell or language.
How would they then be distinguishable from file names on the same
command line?
> Far too often do I make the mistake of thinking that something can
> easily be written using sh, getting deep into it and then wishing I'd
> used perl instead. Yes, it is amazing what an expert can do with sh, but
> developing and debugging a complex sh script can take far too long.
That brings us back to the original cultural decision made in UNIX,
there is not one command language, compiler, text formatter or whatever
which is tied to the system (or built-in) but you can choose whichever
suits your needs best or you can write your own if you like none of
them.
I do occasionally use perl (once every few years) but I can fully
express myself using sh(1) and derived shells (ksh, bash, zsh). Looking
at the footprint of the shells and perl and knowing that every UN*X-like
system I've used since 1983 has some shell which is sh(1) compatible (at
least for 95%) and perl comes in versions (porting from perl 4.036 to
perl 5 cost me a lot of time ten years ago), needs tons of modules (if
you pick perl scripts from the Internet) and is not part of the base
system of FreeBSD (and many other UN*X systems), for me sh(1) is the
natural choice but please choose your own favorite as that's what the
UN*X culture explicitely promotes.
My $.02
Paul Schenkeveld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090718112355.GA99793>