Subject: Re: /bin/sh fixes to make printf a builtin and 'fix' echo
From: David Laight <firstname.lastname@example.org>
Date: 06/11/2002 23:45:28
On Tue, Jun 11, 2002 at 04:39:25PM +0100, Ben Harris wrote:
> In article <20020611140857.G411@snowdrop.l8s.co.uk> you write:
> >options.h: Make 'V' and 'E' (vi and emacs) mutually exclusive,
> > Add new options '-o posix' and '-o SuS'
> Ugh. I'm strongly opposed to having to set options in order to get
> standards conformance, not least because conformant applications can
> probably do something that will turn the option off (e.g. invoking a new
> instance of "sh" after clearing the environment).
yes - the trouble is that doing anything else breaks compatibility
with existing systems.
OTOH even to write C that is XPG4 (say) conformant requires
defining thinks like (I can't remember the exact defines)
in all the source files in order to get the header files to guarantee
to generate the correct data....
> > /*
> > * Echo command.
> >+ *
> >+ * echo is steeped in tradition - several of them!
> >+ * netbsd has supported 'echo [-n | -e] args' in spite of -e not being
> >+ * documented anywhere.
> >+ * Posix requires that -n be supported, output from strings containing
> >+ * \ is implementation defined
> This is untrue.
> IEEE Std 1003.2-1992 makes a first operand of "-n" implementation-defined, and
> arguably allows other options as well. It makes \ implementation-defined.
> IEEE Std 1003.1-2001 disallows all options, and requires SysV \-escapes.
> IEEE Std 1003.1-2001/Cor 1-2002 will make a first operand of "-n" and any \
> implementation defined for POSIX implementations. For XSI
> implementations, its requirements should be the same as .1-2001.
> When writing things that are likely to be persistent (like comments and
> documentation), it's as well to make it clear which version of which POSIX
> standard you're referring to.
Thanks - I don't have the posix specs to hand and was trying to remember
what you had said before...
> >+ * The Single Unix Spec requires that \ escapes be treated (as below)
> >+ * but that -n not be treated as an argument.
Still looks like at least two variants are required though!
There may also be other places where the posix behaviour, SuS
behaviour and netbsd behaviour differ.
David Laight: email@example.com