Subject: Re: test: ==: unexpected operator
To: Hubert Feyrer <hubert@feyrer.de>
From: Perry E. Metzger <perry@piermont.com>
List: tech-userlevel
Date: 09/23/2006 14:11:43
Hubert Feyrer <hubert@feyrer.de> writes:
> For the rest of you: please keep the bikeshed to your own stuff. In
> case you forgot, NetBSD is an operating system to assist users, not
> force anyone's politics upon them. If a user wants to use == instead
> of = and if there's no strong reason to disallow that,

Note, "*AND* if there is no strong reason to disallow that." Emphasis
mine, but I think you should have paid attention to your own words.

Some people here have articulated good reasons not to add the
syntax. The most important reason of all is that people like it when
shell scripts are maximally portable, and not all versions of test
recognize "==", so you don't want to use them in portable
scripts. Absent an error, you won't notice that you've done something
non-portable. I can't think of other constructs like that which we
support as of now -- all our sh extensions are UI things like line
editing.

There are lots of things in ksh and bash but not in our sh. For
example, both have the "[[ ]]" syntax, which POSIX specifically
considered and decided not to implement. There is also ksh style
function declaration, etc. -- I'm not sure we want all those things.

Now, I tend to support adding non-standard extensions when they give
the user the ability to do something they couldn't do before, but this
doesn't let people do something new. I'm not sure it is enough of a
win to outweigh the lose.

>   - Hubert
>     (geez, Kindergarten!)

I think making fun of everyone else's opinion isn't a reasonable
course here. It would perhaps be different if lots of people were
supporting your position, but it appears the opposition is quite
universal.

I also think your case would have been stronger if you hadn't
committed before people came to a consensus.

I've been on the other end of such discussions, and I know it can be
annoying to wait days before committing a seemingly "obvious" change
(or before being told you can never commit it even though, to you, it
is "obviously" right), but the nature of working together as a team is
that sometimes you have to sacrifice the thing you think should
"obviously" be changed because most other people disagree.

-- 
Perry E. Metzger		perry@piermont.com