Actually, if you look at the ARC cases again, there was a recent (within the last year) case that set out to define how an app might move from places like /usr/sfw to /usr to avoid this problem of PATH. (fixing the path madness...)
Saying that, it takes time for this to happen since each project has to be considered on it's own merits to avoid overlap (e.g. GNU find vs Solaris default). So you will find gfind in /usr/bin now. But if you really want to use the GNU version in preference - and still call it "find" - you can add /usr/gnu/bin to the front of your path. I think that there was some mention of having this - use GNU tools in preference- asked somewhere, e.g. at install time, or something, and this could be what you desire. Darren. Richard L. Hamilton wrote: >> On Thu, 28 Feb 2008, Gary Mills wrote: >> >>> There are several places in Opensolaris where PATH >> and MANPATH are set. >>> By default, however, when I rlogin to an Nevada b81 >> release, I find that PATH=/usr/bin >>> and MANPATH is not set at all. This is pitiful! >> Many people assume that nothing else >> is installed on Opensolaris; they build and install >> their own copies. Surely, /usr/sfw/bin >> and /usr/ccs/bin should be in the default PATH, with >> similar directories in MANPATH. >> If the 'man' command still finds the standard manual >> pages (which it >> does), then I think that it is good that MANPATH is >> not set at all >> since it is bad to pollute the user's default >> environment variable >> space with unnecessary environment variables. >> >> I also think that it is good that /usr/sfw/bin is not >> in the PATH by >> default since it is typically full of very outdated >> open source >> software, or software which will become outdated not >> long after a >> release. For example, on a Solaris 10 system, the >> version of >> ImageMagick available is from 2002 and the GNU m4 >> available is too old >> to be used with Autoconf. >> >> I very much wish that the rest of Solaris did not >> depend on anything >> under /usr/sfw, but I spent almost four hours last >> week figuring out >> how to avoid using a library and headers from there >> which were picked >> up due to pkg-config output. In the end I failed and >> had to >> temporarily rename a system directory so I could >> build my software. >> >> Likewise, I don't think that all users need to have >> access to software >> development tools. >> >> A minimal standards-compliant environment should >> continue to be the >> norm for Solaris. With 1048 commands already in >> /usr/bin on Solaris >> 10, it is already becoming a bit bloated. > > A possible compromise might be a simple GUI tool to select > (and sequence) from a list of descriptions of bin directories > typically available, which would then put the corresponding > PATH in as the (first, if it already existed) line of the user's > .profile or .login file as appropriate, and tell them to log out > and back in again to pick up the change. > > That would avoid breaking anything for those that depend > on the default behavior to remain unchanged, while still > making it quite a bit easier to discover that there was other > stuff out there. > > Regarding the selection of PATH elements, perhaps the above > actually describes an "expert" mode, while a basic mode might > simply offer a few choices for common expectations, like > "minimal default", "POSIX compliant", "POSIX with supplementary > Open Source commands", etc; which would correspond to predefined > entire PATH values to set up for the user. > > So rather than changing the default (with whatever breakage that > might or might not cause), why not just make it very easy for > people to discover and choose alternatives for themselves? > > > This message posted from opensolaris.org > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org
