[illumos-Developer] webrev: reimplementation of od

[Garrett D'Amore]

On Sun, 2010-10-17 at 18:19 +0200, Guido Berhoerster wrote:
> * Garrett D'Amore <garrett at nexenta.com> [2010-10-17 17:24]:
> > On Sun, 2010-10-17 at 13:20 +0200, Guido Berhoerster wrote:
> > > * Garrett D'Amore <garrett at nexenta.com> [2010-10-17 07:03]:
> > > > 	c) No support for legacy semantics of "-c".  If you want those in your
> > > > script, run your script with LANG=C (or LC_CTYPE=C), rather than in a
> > > > different locale.  (It will go faster, too!)  The semantics I followed
> > > > are what is required by POSIX.
> > > > 
> > > > 	d) No special interpretation of "-" to mean stdin.  That's verboten by
> > > > POSIX, and the xpg4 version doesn't do it.  So neither does my code.  If
> > > > someone *really* believes they want to mix stdin on the list of files,
> > > > let me know, and I'll craft a version up.  I just think its not very
> > > > worthwhile, its a semantics that is horribly confusing.
> > > 
> > > After the recent (heated) discussion about printf I find this a
> > > bit confusing, what is Illumos general strategy for changes to the
> > > userland? Quirk-by-quirk compatibility in order to prevent
> > > breakage of legacy scripts or modernization and convergence with
> > > /usr/{xpg4,xpg6}/bin?
> > 
> > Generally, I'd prefer to avoid breaking scripts.  Where I can achieve
> > that *without* breaking POSIX compatibility, that's a goal.  In some
> > cases we will have to decide individually. 
> 
> Isn't it the purpose of the different userland personalities to
> prevent having to make such zero-sum decisions?
> 
> > printf was an easy case to decide -- POSIX compatibility was easy (I
> > mean with the standard itself, not with the tests which I affirm are
> > testing behavior that is *not* specified in the standard and not
> > behavior that would be used by compliant scripts).
> > 
> > This one was a bit trickier, but it seemed to me that the legacy Sun
> > behavior was broken beyond belief in certain regards, so I have a hard
> > time believing anyone had scripts relying on it.
> > 
> > Where the Sun code is clearly buggy, I'll choose fixing it over
> > reproducing it.
> 
> a) and b) seem to be clearly broken, but c) and d) appears to be
> odd but documented legacy behavior for the /usr/bin variant. Do
> you intend to replace both /usr/bin/od and /usr/xpg4/bin/od with
> your implementation?

Yes.  If someone convinces me that the legacy behavior is both useful
and desirable, I can add it.  I didn't do it yet because a) it didn't
seem useful, and b) it was just extra work (albeit not a lot). 

In particular, "c"'s behavior is the default for the C locale, or even
for ISO8859 locales.  If you want that behavior for your portable
script, don't run in UTF-8.

"d"'s behavior is just ... strange.  I am doubtful that its that useful
to folks or that there are any scripts coded to that particular
semantic.  If someone disagrees, let me know.  Its in conflict with
POSIX though, so I'd rather *not* do it unless there is a truly
compelling reason.

Generally, I think we have been too afraid to break certain not terribly
useful legacy behaviors.  I think we can reasonably do so to achieve
better conformance to specifications, especially where it can be shown
that the legacy behaviors are not actually useful to 3rd party software.

Eventually I'd like to see us achieve POSIX 2008 by default (i.e. not
need special /usr/xpg7 or whatever in your path).  I have some
enhancements in the queue for libc to address some POSIX 2008
requirements, for example.

	- Garrett