I'll take this off tech-pkg.  I doubt it's of general interest.

> Meanwhile you've go on to invent all kinds of crazy cockamamie
> bastardizations of
> non-shell idioms
Does "shell non-idioms" more closely match your
meaning here?  The "non-shell" is...well...wrong,
since those are all shell syntax.

Eh, sorry, guess I should have parsed that as
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!?!?!?
Nothing.  I like

	while : ; do
		:
	done

or even, in shells that can't complement,

	if neat-o command ; then
		: hey, it worked
	else
		echo 1>&2 Crap, it failed!
	fi

I do have problems invoking : for its side effects.
I've seen this particular idiom confuse clever folk on
at least 2 different occasions.  Heck, I seem to recall
one of the @netbsd.org folk scratching their heads over it
(did a quick search of the mailing lists, but didn't
find it, I think it was in one of the ramdisk building
scripts).

Hm...and mebbe there was some netatalk startup script
that left a Columbia person puzzled.

> The ":" command is specifically designed for this purpose -- or at 
> least
> that's one of its intended purposes.
That's kinda just an asssertion, right?  I mean,
was it *you* who added : to the shell?

>   When used alone like this it
> specifically brings attention to the fact that the expression has
> _intended_ side-effects.
Yeah, yeah, yeah.  So does the oddness of var=${var:-eek}.
The "redundant assignment" is the red flag in this idiom.

>> 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.  :-)
Yes, that was my point.  It's equivalent, to my mind,
to using :.  Both call a command that "does nothing" (well,
effectively nothing) and then use the side effects of
expanding the arguments to that command in setting a var
for later use in the shell.

>> 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.  :-)
Jeez, the equivalence was the point: they are
the same, one is ugly, so both are ugly.  Would
it have helped if I'd written /bin/true?

>> 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! :-)
That was supposed to be sly, see, using : for
its side effect.  What, you like side effects
if they do what you expect, but not otherwise?

Any chance there's a lesson, there, about unexpected side effects :)?

>> 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.
Well, as I wrote, I *do* think so.

> 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!  ;-)
I got no problem with side effects.  Surely mentioning C &
my dawning preference for "[ ${var:=NO} = NO ]" showed that?

It's the tossing away of the variable expansion that bugs me.
You're bugged by the redundancy of self-assignment using :-.
I'm bugged that those vars are likely getting expanded, then
not used.  I claim using an assignment statement when you
want to assign is more clear than using an idiom based in
side effects.  You claim the idiom you like is more common.

OK.  So?

Chris.