[ On Monday, June 10, 2002 at 12:41:24 (+0100), Ben Harris wrote: ]
> Subject: Re: discrepency beteen /bin/echo and builtin echo of /bin/sh
>
> Erm, I think SUSv2 was intended to be aligned with POSIX, so that any SUSv2
> implementation will also be a POSIX implementation.  This is trivially true
> of SUSv3 of course.

"aligned with" != "same as"

The Single unix Standard has clearly been on a track to more practical
standardisation of historical and practical practice than POSIX ever
was.  POSIX always tried to sit on the fence and elected to make no
decision where conflict or politics got involved.

> >  At least it's more practical and pragmatic.  POSIX is stuck in
> >the early 1980's and will undoutably stay there for decades to come,
> >esp. if ISO keeps oversight on it.  POSIX never was practical, not ever,
> 
> As far as I can tell, ISO has far less influence on POSIX than either TOG or
> IEEE these days.

What do you mean by "these days"?  Traditionally POSIX was only IEEE.
These days ISO has (too much, according to many, not just myself)
influence on POSIX.  Perhaps POSIX is pulling back some from ISO for the
time being, but it's not clear it won't get equally or more bogged down
by ISO yet again in the future.

> Hmm.  We discussed this at Reading, but I can't quite remember what we
> concluded that .2-1992 was saying.  The problem is that if "echo" supports
> options, and doesn't support "--" then it's impossible for "echo" to tell
> the difference between options and operands that start with a hyphen.  If
> they default to being options, then the text about a first operand of "-n"
> is spurious (since the first operand can't begin with a hyphen) and if they
> default to operands then "echo" can never take options.  In either case,
> some part of the text is meaningless, which is strange.

That's just plain silly.  It is not important or necessary for "echo" to
support '--'.  "-n" is defined to be only recognized if it is the
_FIRST_ operand.  Within the standard defined behaviour there's no need
to support '--' and so explicitly not recognising it in the standard
makes perfect sense.

Also since the standard explicitly makes the interpretation other option
letters explicitly implementation dependent then an initial "-e" operand
can be explicitly ignored by an implementation without directly breaking
conformance with the standard.

> What we did conclude was that the _intention_ of .2-1992 had been to ban
> any option other than "-n" (the Rationale makes this fairly clear by only
> mentioning "-n" rather than other operands starting with hyphen, e.g. at
> line 6032), and we've made sure that .1-2001/Cor1-2002 will make this
> intention clearer by saying "Implementations shall not support any options"
> and treating an initial "-n" as a potentially-magic operand.

I suggest very strongly that `you' mis-read the rationale!  To me it is
quite clear that the intention was to explicitly make other options
implementation defined and to implicitly suggest that only the first
operand should ever be treated as an option flag.  Such a re-write of
the rationale makes no sense whatsoever.  The only clarification that
could possibly be necessary is adding more explicit wording to indicate
that only the first operand should ever be tested for "flag" behaviour.
To me this is implicit in the explict avoidance of '--' though.

Perhaps more attendees of that meeting should have gone back to original
sources, such as Kernighan & Pike's "The UNIX Programming Environment"
to better learn what the root of the "echo" issue really is.

The standards should allow sane real-world implementation that does as
I've described to be conforming (i.e. what SuSv2 says).  Otherwise the
standards are impractical and inventing rules that do not match
historical practice thus explicitly making legacy applications
non-conforming.  Such is the sad state of too many standards in this
industry today.

In any case it seems that if NetBSD's various "echo" implementations are
to remain practical (i.e. useful with legacy and portable scripts), and
of course be self consistent between themselves, they must follow the
advice of SuSv2, not be strictly minimal implementations of any revision
of POSIX.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>