* Marcus Brinkmann said: > > That's about a *script*, we're talking about the *shell* which is supposed > > to provide every capability in the standard. This means the echo command > > should support both arguments. Whether the script programmer uses them or > > not - it's his problem, shell should support it. > > No, this is not correct. A shell can choose only to implement the > functionality that must > be there according to POSIX and hence be POSIX compliant. If all > implementations had to be fat, there would be no point inn declaring > some features to be optional. But does implementing an *option* allowed by the standard and that is used commonly breaks the standard? No. 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. So, the programmer of the utility should judge where the standard *might* be incorrect and try to adapt the program to the reality. > 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. > The same goes for many other things (for example use of PATH_MAX vs > sysconf etc). Agreed here. marek
Attachment:
pgpibCUOrnbfP.pgp
Description: PGP signature