From: Luke D. <cod...@ho...> - 2002-12-05 11:36:36
|
>From: Soren A <sor...@fa...> >To: min...@li... >Subject: [Mingw-msys] Re: Regarding MSYS release Cands. >Date: Thu, 5 Dec 2002 06:25:56 +0000 (UTC) > >"Luke Dunstan" <cod...@ho...> wrote around 04 Dec 2002 >news:F59...@ho...: > > > That's why I normally put all my custom startup commands in > > $HOME/.profile instead of /etc/profile. Is there a particular reason > > why you can't do this? If something needs to change in /etc/profile > > for a new release, it could be a problem to not overwrite the previous > > version. > >I know, I get that. > >There have been innumerable phases of kludges I've done, some of which >required me to change /etc/profile. There's almost no software that I >won't find a way to 'mess up' by my inner drive to do >experimentation ;-). MSYS isn't exempt. If you don't mind this sort of hacking, then until the MSYS installer is modified I'm sure you could do most things like modifying PATH in .profile. How about using sed or something to remove the "/usr/local/bin" from PATH? :). You could reorder things too. If the installer were to back up /etc/profile you would still need to compare the old/new versions to see if anything needs to be updated in your custom script, so this way might be even easier :) Just an idea... [snip] > > Best, > Soren A > >-- >"So, tell me, my little one-eyed one, on what poor, pitiful, >defenseless planet has my MONSTROSITY been unleashed?" > - Dr. Jumba, Disney's "Lilo & Stitch" Luke _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
From: Soren A <sor...@fa...> - 2002-12-10 20:40:59
|
Hi, Luke! First of all, I am happily resigned to Earnie not changing the MSYS installer in this regard (overwriting /etc/profile) for a long time. Don't want Earnie to get the impression that I am grousing. "Luke Dunstan" <cod...@ho...> wrote in news:F12...@ho...: > > "Luke Dunstan" <cod...@ho...> wrote around 04 Dec 2002 > > news:F59...@ho...: > > > That's why I normally put all my custom startup commands in > > > $HOME/.profile instead of /etc/profile. Is there a particular > > > reason why you can't do this? If something needs to change in > > > /etc/profile for a new release, it could be a problem to not > > > overwrite the previous version. > > I know, I get that. > > > > There have been innumerable phases of kludges I've done, some of > > which required me to change /etc/profile. There's almost no software > > that I won't find a way to 'mess up' by my inner drive to do > > experimentation ;-). MSYS isn't exempt. > If you don't mind this sort of hacking, then until the MSYS installer > is modified I'm sure you could do most things like modifying PATH in > .profile. How about using sed or something to remove the > "/usr/local/bin" from PATH? :). You could reorder things too. If the > installer were to back up /etc/profile you would still need to compare > the old/new versions to see if anything needs to be updated in your > custom script, so this way might be even easier :) > > Just an idea... No, it's OK, of course I am aware of this possibility. The thing is that I'd like to avoid it as much as possible. Manipulation of PATHs in shell scripting is, IMO, both error-prone and markedly harmful to (start-up) performance. In particular I would like to avoid massive numbers of calls to external programs like sed. I have come across (in the past) sites that offered very sophisticated-looking PATH manipulation scripts (the terminology I've mentioned, "pathel" for PATH ELement, I borrowed from one such site's explanation -- I believe it should come into common usage). So I know that it is *possible* to do nearly anything with PATHs in bash, but it isn't necessarily very enjoyable to undertake. I wrote a way that starts no external programs and therefore, in principle, might have minimal impact on the login start-up time. Yes, of course I am going to show you (all). It seems I can hardly be stopped from doing so after all ... ;-) if [[ $PATH == .:/usr/local/bin:* ]] && [ ! -d /usr/local/bin ] then NOT_wanted='/usr/local/bin:' KEEP_cwd='.:' export PATH=${PATH/#$KEEP_cwd$NOT_wanted/$KEEP_cwd} unset KEEP_cwd NOT_wanted fi This of course goes in the ~/.profile bash initfile. This gets rid of the bogus pathel without nuking the cwd at the front of PATH. Best, Soren A -- Yes, it's really Sören, not Soren. |
From: Earnie B. <ear...@ya...> - 2002-12-10 20:58:24
|
Soren A wrote: > > I wrote a way that starts no external programs and therefore, in > principle, might have minimal impact on the login start-up time. Yes, of > course I am going to show you (all). It seems I can hardly be stopped > from doing so after all ... ;-) > > if [[ $PATH == .:/usr/local/bin:* ]] && [ ! -d /usr/local/bin ] > then > > NOT_wanted='/usr/local/bin:' > KEEP_cwd='.:' > export PATH=${PATH/#$KEEP_cwd$NOT_wanted/$KEEP_cwd} > unset KEEP_cwd NOT_wanted > > fi > > This of course goes in the ~/.profile bash initfile. > > This gets rid of the bogus pathel without nuking the cwd at the front of > PATH. > Interesting, perhaps 1.0.9 will contain a modified version of this. Earnie. |
From: Soren A <sor...@fa...> - 2002-12-11 06:18:26
|
Earnie Boyd <ear...@ya...> wrote in news:3DF...@ya...: > > This gets rid of the bogus pathel without nuking the cwd at the > > front of PATH. > > Interesting, perhaps 1.0.9 will contain a modified version of this. :-). Soren |