Given that the point of this case is to remodel the OpenSolaris ls to be more like the GNU ls I can say that the "when in Rome" rule from CLIP applies here and long options without a corresponding short one should be allowed. That is after all the point of this case, to make the OpenSolaris /usr/bin/ls more like the /usr/gnu/bin/ls one while still maintaining its OpenSolaris unique features.
So does this set precedence to ignore the CLIP restriction ? No I don't think it does since all the long options introduced in this case have a 1:1 match in the corresponding GNU program. If on the other hand the case attempted to add new long options (without matching short ones) to ls that had no corresponding GNU option then I'd say it possibly violates the intent of the CLIP case. Or if that doesn't convince, my opinion is that GNU getopt got it correct and the CLIP case got it wrong. That is I fully support long options that have no corresponding short option, otherwise IMO there was really little point in adding the long options as all it reduces to is an alias, when the real point was moving beyond 26 (or may 26+9+some other small number for strange stuff like -/ and -@). So as far as long options are concerned I have no issue with this case. Before I give full endorsement I would like to review a table (or other way or presenting the data) that shows where the /usr/bin/ls would still be lacking from the GNU one, though I doubt the content of it will sway my choice (which is likely to be approval). -- Darren J Moffat
