On 03/ 2/10 01:44 PM, Peter Tribble wrote:
On Tue, Mar 2, 2010 at 3:47 PM, Garrett D'Amore<[email protected]> wrote:On 03/ 2/10 03:57 AM, [email protected] wrote:On Tue, Mar 2, 2010 at 7:02 AM, Garrett D'Amore<[email protected]> wrote:I'm just thinking, isn't it time we just bit the bullet and told our users to start using the POSIX defaults, instead of continuing to supply the legacy compatibility stuff forever.I believe a number of scripts requires certain tools from that package so I think we always need to install them; however, I think it is better that we try our level to merge them into the standard location.And *that* is what I was saying. I think we should finally adopt the POSIX semantics.Provided it's a reasonable merge. For example, I updated du (seems like ages ago now) so that the regular and xpg4 versions both understood -d and -x. There are going to be some differences that are unavoidable, but allowing the use of common old-fashioned flags where there aren't conflicts makes transition so much easier. I haven't looked recently to see how big a problem this is still. What I do know is that working in a heterogeneous environment (and with different configurations mixed in) the minor differences in behaviour drive me up the wall.
The point here is that in OpenSolaris/Solaris Next, maybe we can finally ditch the legacy Sun semantics. I'd only do that where we couldn't *adopt* the Sun semantics as is. For example, command line switches only understood by the non-XPG4 version could be incorporated into the merged version.
The tricky part is dealing with the subtle semantic differences. For example, what does date +%C output? For /usr/bin, its the default strftime output. For standard conforming date it is the century number. (Which means you should never use %C in a date format string in a portable shell script! :-) Its these kinds of legacy Sun semantics that I think we can finally bite the bullet and eliminate, offering the POSIX conformant semantics instead.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
