Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000762 [1003.1(2008)/Issue 7] Shell and Utilities Objection Enhancement Request 2013-10-10 01:11 2013-10-31 15:59
Reporter dwheeler View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
Name David A. Wheeler
Organization
User Reference
Section test
Page Number  3224-3225
Line Number 107503-107513
Interp Status ---
Final Accepted Text
Summary 0000762: Add "==" as synonym for "=" in test
Description Many implementations of "test" (aka "["), including shell built-ins, implement "==" as a synonym for "=", and this synonym is widely used. I propose standardizing this common practice.

There are three major reasons for adding “==” as a primary:
1. Primary “==” is more visually distinct from assignment (“=”). Since “=” is also used for assignment in shell scripts, using “==” for “is equals” makes the comparison visually distinctive, making it clearer to readers that “is equals” is intended.
2. Allowing “==” for “is-equal-to” adds consistency with other programming languages that use “=” for assignment. Most languages that use “=” for assignment also use “==” for “is equals” so that these operations are more visually distinct. These include C, C++, Java, C#, Python, and Perl. It is oddly inconsistent that test/[ do not support “==” as well. Many languages (like Pascal) that use "=" for comparison use another spelling (like ":=") for assignment, again, to keep their spellings separate. In some cases these languages can always disambiguate from context, and even then, they intentionally do not use the same spelling. It's too late to get rid of "=" for comparison, but it's easy to add "==" as a synonym, which is what is proposed.
3. Primary “==” is already widely implemented in many implementations and is used in many shell scripts. Indeed, many people are surprised that "==" is not in POSIX already; https://wiki.ubuntu.com/DashAsBinSh [^] says that a "very common pitfall" in using dash is that dash doesn't support "==". Since this is a common expectation, this suggests that there is value in standardizing it.

Support for "==" is already implemented in bash, pdksh (http://web.cs.mun.ca/~michael/pdksh/pdksh-man.html), [^] mksh (MirBSD(TM) Korn Shell, http://www.mirbsd.org/mksh.htm), [^] GNU coreutils' test (added on 2011-03-22), OpenBSD's /bin/sh(it's not documented but it DOES work), FreeBSD-current's /bin/sh and /bin/test (see http://svn.freebsd.org/base/head/bin/test/test.c), [^] busybox ash, and busybox sh. Dash does not, but it would literally take 1 line to add (http://permalink.gmane.org/gmane.comp.shells.dash/498), [^] and they appear willing if it's added to POSIX. The fact that even *busybox* has this facility, even though it's targeted at small systems, is telling.

A counter-argument to adding “==” is that it is redundant with “=”. This is true, but there are many other redundancies in POSIX. For example, “[” is redundant with “test” but this is not considered a problem. In any case, it is a redundancy that is considered valuable by many; “=” came first, and many implementers have added “==” since.

*ALL* of the implementations agree that "==" is a synonym for "=", so there's no question about conflicting semantics.

This was originally proposed in bug #375 (http://austingroupbugs.net/view.php?id=375), [^] but now I think that report combined too many different proposals. So I'm proposing "==" here as a separate bug report, to make it easier for the POSIX committee to consider adding it.
Desired Action Add to the list of primaries for "test" (circa page 3224):

* s1 == s2 True if the strings s1 and s2 are identical; otherwise, false. This primary is equivalent to s1 = s2.
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0000375Appliedajosey Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef 

-  Notes
(0001923)
ranjit (reporter)
2013-10-17 02:05

 I agree with the comments in the other bug which say this is a redundant
extension. Personally I find it aesthetically really awful (in language-design terms) as well.

"adding "==" (1) clarifies whether assignment or comparison is being used" is *completely* untrue.
As jsonn pointed out: foo=$bar and: [ "$foo" = "$bar" ] can never be confused by anyone who's used sh for more than 5 minutes. Nor is there any real confusion about what the latter means to people who do not know sh; [ ... ] demarcates a boolean test. The language is *self*-consistent and /that/ is what matters.

"It's the usual way to get better ideas tried out before they're standardized, and once they're in the standard, they aren't "vendor extensions" - they ARE part of the standard."
..presumes that this is a better idea than simply sticking to = in sh.

The simple fact of the matter is that sh is not any of the other languages you mention: it has its own idioms. So the argument: "(2) improves consistency between shell and the MANY other languages that use "=" for assignment" is completely off-wack as well.

On a language design level, having two operators mean exactly the same thing is simply awful. As pointed out in the other bug, where languages have two operators, they have different meanings; and == means a numeric comparison in $(( )) already.

It's redundant and unclean in language design terms. As markh said:
"For someone writing a shell script, it would seem to be better if their implementation did not support the "==" extension and instead produced an error."
I totally concur: since it would make it clear to the newbie that they are not in another language, and should not expect anything like the same setup.

I note in passing that you ignored this point in the other bug, but it's critical when you are discussing language-design.

"Redundancy for backwards-compatibility is perfectly reasonable" is correct: however the string equality operator is not being phased out, nor is anyone suggesting that. So 'backwards-compatibility' is a misnomer. All you are talking about is adding another operator so that people who do not know sh (and are apparently unwilling to learn) can rely on "muscle memory" which afaic is a stupid idea: I'd prefer them to realise they're scripting sh, and be whacked over the head with that fact when they slip up, so that they focus on what they're actually doing, *before* someone else uses their output.

That this is "implemented widely" is imo part of the reason so many bash scripts are crap: people transfer "knowledge" from other domains and presume "shell is easy" (ofc it is: it's designed to make sense of user input at a terminal) until they mess up when it turns into a snobbery about shell, instead of a realisation that they never actually bothered to learn it in the first place.

"Everyone uses BASH" so others implement it for compatibility: that does not mean it's a good idea. Most telling for me was jsonn's comment:
"Imagine for a moment that GNU bash wouldn't silently provide this "feature" even in /bin/sh mode. The basic result would be that noone would use it and we would not have this discussion about adding a redundant operator."

In summary I do not support this at all; it is not the job of a standardisation committee to add new operators that are exactly the same as old ones and thus bastardise a language. The comment "while the semantic is the same, the spelling is different" makes me want to vomit (with the greatest respect to you and the work you do.)

As with others, I do support -nt and -ot. Note none of this is about "how much work" this does not add: 'conceding' that as an argument in your final note on the other bug, simply indicates that you have dismissed the other points put to you-- not that those points are invalid.
(0001948)
Don Cragun (manager)
2013-10-31 15:59

 It is our belief that test expr and [ expr ] should be made obsolescent (although never be removed from the standard) and that [[ expr ]] should be added to the next revision of the standard (which will be done by 0000375).

Although implementations are free to add == and a synonym for = in test and [, there is no need to extend obsolescent features to require this to work.

This was discussed at length during the October 31, 2013 conference call.

- Issue History
Date Modified Username Field Change
2013-10-10 01:11 dwheeler New Issue
2013-10-10 01:11 dwheeler Status New => Under Review
2013-10-10 01:11 dwheeler Assigned To => ajosey
2013-10-10 01:11 dwheeler Name => David A. Wheeler
2013-10-10 01:11 dwheeler Section => test
2013-10-10 01:11 dwheeler Page Number => 3224-3225
2013-10-10 01:11 dwheeler Line Number => 107503-107513
2013-10-10 07:07 olof Issue Monitored: olof
2013-10-17 02:05 ranjit Note Added: 0001923
2013-10-17 02:38 eadler Issue Monitored: eadler
2013-10-31 15:55 Don Cragun Relationship added duplicate of 0000375
2013-10-31 15:59 Don Cragun Interp Status => ---
2013-10-31 15:59 Don Cragun Note Added: 0001948
2013-10-31 15:59 Don Cragun Status Under Review => Closed
2013-10-31 15:59 Don Cragun Resolution Open => Rejected

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker