Christopher Yeoh <[EMAIL PROTECTED]> writes: > > - 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.
That makes sense, but perhaps the spec should make a point of saying that only the existence of the command and its general behavior are guaranteed - that its prompts and such may change. It worries me a bit that developers may be misled into thinking that su or passwd or whatever have a fixed ABI. > 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). I'd agree that useful extensions to the SUS make sense. I don't see including extensions that are clearly silly like --debug, or those that are not especially useful and conflict with (vs. extend) the SUS, though, such as df -t. Just adding a note that POSIXLY_CORRECT may change behavior is a possible compromise here. As currently written, I don't think it's possible to be both SUS and LSB compliant, and that's kind of an unfortunate limitation for Linux. I didn't see any cases in the "commands" section where the SUS/LSB conflict was really compellingly worth having. Havoc
