Re: [PATCH] latest ash has broken 'echo' command
On Fri, Oct 22, 1999 at 03:58:46PM +0200, Marek Habersack wrote:
> But does implementing an *option* allowed by the standard and that is used
> commonly breaks the standard? No.
No, indeed.
> Might the standard be wrong by stating
> that some feature is only optional while so many things rely on it as being
> a *standard* one? Yes, it can be wrong.
A standard can never be wrong by definition. It can be contradictional, or
it can be inappropriate or obsolete. But it can never be wrong.
> So, the programmer of the utility
> should judge where the standard *might* be incorrect and try to adapt the
> program to the reality.
Whatever. But he must not claim compatibility to the standard if he does not
adhere to it. Deal with it.
> > Either you choose to be unportable and make use of optional features, or
> > you
> > aim at compatibility and don't use optional features without checking if
> > they exist.
> Optional features defined in the standard *are* compatible. The only way
> required is a way to notify the programmer that this particular
> implementation doesn't support this or that feature.
Yes. This is what I say. If your program ONLY works if an optional feature
is available, your program lacks portability to all systems which comply to
the standard, because it will not run on all standard compatible
environments, only on those who provide the feature.
Another example: Many programs (including ash), use PATH_MAX. If you depend
on PATH_MAX, your program is not fully POSIX compatible, because not all
POSIX systems define PATH_MAX in the header files. In this case, you should
check with #ifdef and if it is not defined, query with sysconf (this is
such a way to notify the programmer you mentioned). If sysconf returns -1,
you have to deal with path names of arbitrary length.
It seems that in this case, it is not exactly clear which standard we want
to comply to (SuS may not be the best choice), and what the standard
requests (nobody quoted POSIX verbatim, for example). Also, it is unclear if
all packages should comply to this standard or only the core packages.
I agree that there is apparently no trivial way to check if -n is supported.
But it is possible, and one solution would be to check this and deal with
both cases.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: