Subject: Re: Stupid sh tricks [ was Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d ]
To: Chris Jepeway <>
From: Greg A. Woods <>
List: tech-pkg
Date: 12/29/2004 23:32:46
[ On Wednesday, December 29, 2004 at 21:59:09 (-0500), Chris Jepeway wrote: ]
> Subject: Stupid sh tricks [ was Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d ]
> Ah, but it's clearly an assignment statement.
> You call it "fake."  I call it "less opaque."

Yeah, but it's a doubly redundant assignment that still needs the "test
if set or empty" operator.  I claim there's been nothing opaque about
the ${var=VALUE} form for over two decades now.  :-)

Meanwhile you've go on to invent all kinds of crazy cockamamie
bastardizations of non-shell idioms to show how you'd rather avoid this
very normal, common, shell construct.

What problem do you have with using the ":" builtin command!?!?!?

The ":" command is specifically designed for this purpose -- or at least
that's one of its intended purposes.  When used alone like this it
specifically brings attention to the fact that the expression has
_intended_ side-effects.

> and consider it about as "desirable" as doing s/t like
> 	echo > /dev/null ${cups:=NO}

I can't even imagine how you could even begin to consider such a thing....

Obviously that ugliness is not desirable in the least.  :-)

> or even
> 	true ${cups:=NO}

Well except for the fact that "true" need not be a builtin command, that
is _identical_ to the much more common, much more readable, and often
more efficient ": ${cups:=NO}" form.  :-)

> Heck, given the precedent of C, I've about talked myself
> into preferring this
> 	if [ ${cups:=NO} != NO ] ; then
> 		: Start cups
> 	fi
> (which I've never seen in the wild) to relying on the
> side effects of executing a command that does nothing.

I have often enough seen the likes of that form, but it hides the
side-effect, which makes the code noticably harder to understand.

(hmmm... there you've even used the ":" command to combine a no-op
statement and a comment into one! :-)

> Well, sez me.  And that was my point: there's a
> tenable position to take that := isn't as clear as assigning
> a value that's defaulted by :-.

No, I don't think so.  The ${var=VALUE} and ${var:=VALUE} forms are
extremely clear and quite common uses of well known shell assigment
syntax, and in conjuntion with the ":" command form a very clear
distinct and recognizable and common enough idiom which avoids having to
use the much more cumbersome test(s) followed by the more simple
assignment syntax using the plain "=" operator outside of an expansion

Like it or not many languages provide expression syntax which might have
various kinds of side effects, and the shell is one of them.  Many even
work this way from the ground up!  ;-)

Avoiding ": ${var:=VALUE}" in shell is as crazy as avoiding "e ? a : b"
in C!  They're both highly recognizable, and quite common, idioms.

						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>