Hi, I'm not normally involved in LSB stuff and haven't followed this list, but have been writing some docs for Red Hat related to the "Command Behavior" section and saw the link to the nice review form on Slashdot yesterday, so just went through the commands section and filed a bunch of bugs. I know it's annoying to do that mere hours after the deadline. ;-) As I said, I am clueless LSB-wise. Hopefully the comments are useful for the next version of the spec.
I filed separate reports for each change but they are mostly in some major groups: - command line options that conflict with SUS in current implementations but are not really essential should not be specified. e.g. "df -t" can just be left implementation dependent, there is no reason to force SUS incompliance here, the option isn't exactly a vital feature. At minimum, annotation should be added that POSIXLY_CORRECT may change the behavior of these options, right? - 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 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). Due to internationalization, checks such as isatty(), possible UI enhancements that change prompts, etc., interactive command behavior is just not a reasonable thing to rely on. Something I didn't file bugs on for the most part: in many cases LSB seems to simply catalog all options in some version of a utility. Wouldn't it be better to start with SUS options and conservatively add only some of the really useful extensions, instead of listing them wholesale? 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? Thanks for everyone's hard work. Havoc
