Havoc Pennington writes: > - the wording "--foo is not supported" seems to imply that an > option must not be supported, though I doubt that was intended. > I think wording such as "--foo is undefined" or "--foo is > implementation-dependent" would be better.
I agree the wording could be clearer. The above sort of wording is used where an option for a command is required by the SUS but at the time of the writing of the specifiction was not supported by the implementations of that command on Linux. In other words for people porting to Linux they can't rely on that behaviour even if their app is SUS compliant. > - I don't understand why the LSB specifies interactive programs; > those are not designed to be an ABI/API and are not a reasonable > ABI/API. For example, I don't see how "su" can be used > programatically (or if it can, only its noninteractive aspects > should be described in the spec, IMO). Some interactive programs are useful when developers want to give users documentation on what to do when some manual configuration or repairing is required. > I did file a bug on one egregious example, "patch --debug" makes no > sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV > app should or could use that option, so why is it required for LSB > compliance? I agree this option didn't need to have been included. In general I think that including options beyond what is required by SUS is better as writing scripts can be a lot easier when you don't have to constrain yourself to SUS only options. From a distribution implementation point of view the options that were included with the commands were a subset that existed on most distributions (except in cases where implementations of a given command were so different between distributions that the one that was seen as best was chosen). Regards, Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia
