> Sasidhar Kasturi wrote: > > Thank you, > > Is it that /usr/bin binaries are more > advanced than that of > > /xpg4 things or .. the extensions of the /xpg4 > things? > > They *should* be the same level of "advancement", but > each has a > different set of promises and expectations it needs > to live up to... > > > > > If i want to make some modifications in the code.. > Can i do it for > > /xpg4/bin commands or .. i should do it for > /usr/bin commands?? > > > If you are doing this "just for yourself", it doesn't > matter - fix > the one you use. If you intend to push these changes > back into the > OS.o source base, you will need to make the changes > to both (and, > possibly interact with the OpenSolaris ARC Community > if your changes > affect the architecture/interfaces of the commands). > > In the case of df, I'm not at all sure why the two > commands are > different. (I'm sure someone else will chime in and > educate me :-)
df(1m) man page seems to identify the difference as a -v option for /usr/bin/df, and a -P option for /usr/xpg4/bin/df. The Single Unix Specification v3 appears to require the -P option: http://www.opengroup.org/onlinepubs/009695399/utilities/df.html Both come from the same source file: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/df.c differentiated on whether or not XPG4 is defined on the compiler command line. (A look at the source shows additional differences of the width of a couple of columns in certain output formats, and of the field names in the header.) Since those options don't conflict, unless some other custom or requirement reserves one or both of those options for some global meaning if not otherwise used (like maybe -v as verbose), I don't understand why both couldn't provide both options; even if the output format difference needs to be maintained, that would make the usage identical, and simplify both code and man page, minimizing the differences. As an example of an addition to both in the not that distant past, consider the -h option (more human-readable scaled output, i.e. K, M, G, etc); I think this was PSARC 2001/183, which appears not to have been opened; I don't know if any others, aside from one for a generic scaled-output routine, apply to that particular example. Which, in conjunction with some of the other discussion in this thread, gets me to thinking that cases that are (then or later) taken as setting precedent beyond just what they enumerate (i.e. beyond just specific commands or library routines or the like) should be considered for opening on additional triggers (such as whenever a RFE or reference to them in a new case appears), not just on request only; if not entirely, than at least in the part that establishes a broad precedent. And it might be handy if there were an index of such precedents; the easier they were to find, the more they could be honored, without causing delays to revise new cases for compliance. (cc'd arc-discuss, due to nature of my digressions) This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
