I took a different approach to do something very similar. I used an env file where all the executable locations were defined and also built a few aliases. I then used uname to detect the os and source the appropriate file. Wrapped that in a single file something so my scripts started with ". ~/bin/loadenvexes.sh" and I was good to go. Worked well across sol/osol/oi, Mac, and several flavors of Linux.
-- Sent from my Jelly Bean Galaxy Nexus Reginald Beardsley <[email protected]> wrote: > > >--- On Wed, 10/17/12, Udo Grabowski (IMK) <[email protected]> wrote: > >> From: Udo Grabowski (IMK) <[email protected]> >> Subject: Re: [OpenIndiana-discuss] Namespace management and symlinks in /usr >> To: "Discussion list for OpenIndiana" <[email protected]> >> Date: Wednesday, October 17, 2012, 10:11 AM >> On 17/10/2012 16:50, Reginald >> Beardsley wrote: >> > In chasing the Firefox/Java issue, I happened to look >> at the symlinks in /usr. I'm rather disturbed by what >> I find. >> > >> > There are 15715 in my installation of oi_151a. >> > ... >> > Yes, it is painful to force people to fix their >> scripts, but in the end, indulging bad behavior just makes >> the problem worse. >> > Having written scripts that ran cleanly across Ultrix, >> SunOS, AIX, HPUX, Irix and more I know it's not hard to do >> things w/o >> > resorting to polluting the system namespace w/ >> bandaids. >> > >> >> This is for people running heterogenous systems, like old >> Osol >> combined with new OI, or for people upgrading from Osol to >> OI >> for not having trouble with scripts after upgrade, and >> problems >> with configure setups for software (on solaris you usually >> have >> to patch configure scripts, and it's a pain to redo this on >> every upgrade). So having these symlinks is a good thing, >> and >> when these old systems gradually die away, people will >> adapt >> their scripts, but at least up to the next stable release >> of >> OI these links should be kept. As there's usually not much >> left in >> these legacy directories, they will quickly become a simple >> symlink to the default places. > >To paraphrase your response: >" >"These links are good because they keep people from having to fix badly >written scripts. > >When there are more symlinks people will fix their scripts." > >It's been my observation that rather than fix the badly written scripts, they >just write more badly written scripts and the problem gets worse rather than >better. > >The following *really* isn't a lot of work the first time, and it's easy to >fix when it does break. When I was writing scripts that needed to run across >6 distinct flavors of Unix, I had a boilerplate file I placed at the start of >the scripts to handle all this stuff. Typically took about 10-15 minutes to >update all the path information for a new platform and that was for a version >control and build system I wrote. > >if [ -e /usr/sfw/bin/fubar ] > then > FUBAR=/usr/sfw/bin/fubar > >elif [ -e /usr/bin/fubar ] > then > FUBAR=/usr/bin/fubar > >else > echo "Can't find fubar" > exit > >fi > > >As for ./configure, setting PATH properly will take care of most of those. >The ones it won't fix generally can't be fixed. > >Reg > >_______________________________________________ >OpenIndiana-discuss mailing list >[email protected] >http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
