[...] > > Not that /usr/ucb in $PATH is something you should > do. (Hm, let's > merge the two ps'es and the whole /usr/ucb thing > becomes mostly moot > anyway.
I would suppose that all the stuff that's only in /usr/ucb ought to be in /usr/bin anyway, with symlinks in /usr/ucb for anyone that had it hardcoded. Some of the odds&ends unique to there are occasionally useful (tset has its moments for remote terminal access, the old *plot stuff is still not quite useless, etc). A merged ps would be nice - there are some things about /usr/ucb/ps that are still handy, like access to full command line args or environment variables (rather than just the 80 bytes saved in the u area for easy retrieval); esp. with stuff like sendmail that modifies its args to show its status. df, du, and file in /usr/ucb are apparently just shell wrappers that fiddle with the options so as to invoke the regular ones in a more or less BSD compatible way. By my reckoning (looking at Solaris 10 as an example, since that's the newest thing I have handy at the moment), that leaves the /usr/ucb versions of basename, chown, echo, expr, groups, ln, ls, sed, stty, sum, test, touch, tr, and of course the evil /usr/ucb/cc wrapper. I suppose those /usr/ucb versions still have their occasional uses; I've used that version of sum once or twice (although a quick test looks like it's the same as /usr/bin/sum -r, so I wonder why it isn't just a wrapper). No doubt there's the odd script out there somewhere that still depends on the behavior of the /usr/ucb alternative versions. Does /usr/ucb/cc work under _any_ circumstances (e.g. with a recent version of Studio compilers installed, to include the link or whatever at /usr/ccs/bin/ucbcc)? If so, maybe it at least ought to output a warning message to the effect that it's probably not what one wants (and maybe try to dig out where cc in any installed versions of SUNWspro or whatever pkg contains gcc might be to suggest them instead), since people stumble across it by accident almost certainly more often than they intend to use it. I'd hesitate to say it should just be deleted, but it should at least admit to its evil nature. I would think that would be about the most cleanup of /usr/ucb that could reasonably be achieved, and by putting everything unique to there into /usr/bin (and perhaps merging ps, although I usually have /usr/ucb at the _end_ of my PATH and thus have to type in full /usr/ucb/ps anyway), that would remove any reason that 99% of people have for putting /usr/ucb onto their PATH. Old scripts would still need it, but otherwise most people wouldn't need to know about it, or if they did, they could remove it from their .profile/.login/whatever. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
