Re: bugs just filed
Christopher Yeoh <cyeoh@samba.org> 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
Reply to: