[illumos-Developer] webrev: reimplementation of od

[Guido Berhoerster]

* 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?

-- 
Guido Berhoerster