Best way to set environment? - Page 4

05-10-2002, 02:03 AM

Gvim? sao, I tried doing fink list but didn't come up with gvim. Is it unstable still? Wow this post is old. Ok here's my 2 cents: its my ugly ungainly PID getter. It's a Frankenscript that I've thrown together, and while it won't bring about world peace, it was fun researching, and has taught me a lot. In bash, this goes in your .bash_profile, .bashrc, .bash_alias, or in your ear

:

gpid () { ps ax | grep "$*" | grep -v grep | awk '{ print $1 }' ; }

then you type

gpid Mozilla

and you get the PID for Mozilla. In tcsh, I think it'd be something like:

alias gpid 'ps ax | grep "\!*" | grep -v grep | awk '{ print $1 }''

but I'm not sure, since I haven't been able to to test it. While I'm here, merv (and everyone else), I'm still a little unclear on this .bash_profile vs. .bashrc thing. I understand (I think) that .bashrc is used for non interactive sub process thingies, but is there a need for .bashrc and .bash_profile to be different? Fer example, when I pop open an xterm in Windowmaker, it seems to read from .bashrc, so I'd like all my stuff to be the same as when I'm in Terminal.app. Am I a nut for considering removing .bashrc and replacing it with a symlink to .bash_profile so they'll always be the same and so I don't have to go edit the other when I make changes to the first? Thanks

sao · 05-10-2002, 02:37 AM

Hi Timan,

If you install VIM - Vi IMproved 6.1, with fink, you also get the GUI version gvim.

system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/sw/share/vim"

which gvim
sw/bin/gvim

Package vim
In 0.4.0-stable: *** Version 6.0-2
In current-stable: *** Version 6.0-2
In current-unstable: *** Version 6.1-1

Description: ***Improved version of the editor "vi"

VIM adds many of the features that you would expect in an editor: Unlimited undo, syntax coloring, split windows, visual selection, graphical user interface (read: menus, mouse control, scrollbars, text selection), and much much more.

Cheers...

PS: Wow Timan, you started this thread, and still is alive and well.

05-10-2002, 03:05 PM

sao, thanks! I got vim, so now to play with it...(good thing I'm off from work today)

mervTormel · 05-10-2002, 05:04 PM

Quote:


	Originally posted by Titanium Man ...I'm still a little unclear on this .bash_profile vs. .bashrc thing. I understand (I think) that .bashrc is used for non interactive sub process thingies, but is there a need for .bashrc and .bash_profile to be different? ...Am I a nut for considering removing .bashrc and replacing it with a symlink to .bash_profile so they'll always be the same and so I don't have to go edit the other when I make changes to the first?

HTH

.bash_profile is run under the conditions of a new login. therefore, it is only run once for that shell window (in terminal.app's case). however, .bashrc is run under the conditions of a sub-shell and .bash_profile is skipped in a sub-shell. so, what does that mean?

in .bash_profile, you can run commands that write to stdout. you wouldn't want chatty commands when you start a sub-shell. the PATH variable should be finalized in .bash_profile. this is so that sub-shells don't alter/prepend/append to it. since fink's init sets PATH and exports some variables, run fink's init from .bash_profile. also, run your .bashrc from .bash_profile

.bashrc is the driver for everything else, aliases, functions, completions, prompt-string, env settings, etc. they should be silent settings, i.e., no noise to stdout.

the PS1 string should be set in .bashrc. this is because non-interactive bashes go out of their way to unset PS1.

to see the effect of .bashrc, start a sub-shell like so: $ bash -xv

so, in review, .bash_profile = main driver and chatty on login ; .bashrc = silent creator of your underworld elements.

here's an example .bash_profile that is very verbose; compare this to starting a subshell (i.e., $ bash) :

Code:

##
# file: ~/.bash_profile
##

# fix MANPATH for man files in /usr/local/man

export MANPATH=\
"${HOME}/man:/usr/local/man:/usr/local/share/man:/usr/share/man"

# bash path wrangling

export PATH # path has been set somewhere in the bowels of startup

pwrangle () # march thru path elements removing non-existent ones
{
  local dlist=$PATH
  local p=""
  local IFS=": "

  for x in $dlist;
  do
    if [ -d $x ] ; then p=$p:$x ; fi
  done

  export PATH="${HOME}/bin${p}" ;
}

# why pwrangle here? in case i want to promote my ${HOME}/bin 
# to be the first dir in my path, i would move the call to pwrangle 
# after the fink init.

pwrangle

# fink init

if [ -f /sw/bin/init.sh ]; then . /sw/bin/init.sh ; fi

# load up the goods

if [ -f ~/.bashrc ]; then . ~/.bashrc ; fi

biff y

# reports - the chatty part

date +"%a %e %b %Y @ %T %Z"
uptime
who
ps a
ps axhum | head -10 # top 10 RAM eaters
vm_stat | grep pageouts
netstat -in
echo "home size: `du -sh ~`"
echo ".-_-.-_-.-_-."
fortune # -o
echo ".-_-.-_-.-_-."
cd

# end: ~/.bash_profile

05-10-2002, 05:25 PM

DING! That was the sound of a lightbulb coming on. The lightbulb over my head. So, .bash_profile is for when logging in, and you can put the "chatty" stuff there, and .bashrc is for other stuff, sub-shells, etc. This is going to be very useful info, merv. Thanks!

vonleigh · 05-10-2002, 06:59 PM

Hello,

I'm actually interested in just adding a gpid command (for getting pid's). I looked at the example above (for tcsh) that read:

gpid 'ps ax | grep "\!*" | grep -v grep | awk '{ print $1 }''

And it didn't work, any other way of doing it?

Thanks,
Vonleigh

mervTormel · 05-10-2002, 07:44 PM

tcsh's quoting can become quite onerous. and the forum's editor strips
un-double-quoted backslashes. this should get it...

Code:

% alias gpid 'ps wwax | grep "\!*" | grep -v grep | awk '\\''{print $1}'\\'''

be aware of single ticks vs. double quotes; the only thing double quoted
is the "\!*"

also, be aware that you can't rely on this too much for an accurate return.
you have to have high confidence that your search arg is completely unique.

e.g., try:

% gpid ic

you wouldn't want to, say, kill, it's return value

vonleigh · 05-10-2002, 08:19 PM

Hello,

Thanks MT, you've helped me on too many ocassions already

One last question, is there any way to make it ignore capitalization? for example if i do: gpid omni, or gpid Omniweb, it won't find anything because it's "OmniWeb".

Thanks,
Vonleigh

mervTormel · 05-10-2002, 08:27 PM

oh, that would be grep -i (gnu's allows --ignore-case)

see the grep man pages, right?

vonleigh · 05-11-2002, 08:23 AM

Hi mt,

Duh! that's so obvious. For some reason I was thinking of some strange solution like the tip about setting upper to lowercase, something really involved. Never thought to just tell grep to ignore case. I'll read the man pages.

Vonleigh

Justin Sane · 11-27-2002, 06:41 PM

Its dirt simple and uninspiringly unclever, but to keep track of everything I add the following line to files:

For example in path:
PATH_INIT = `date +%y%m%d-%H%M%S`
In .tcshrc
TCSHRC_INIT = `date +%y%m%d-%H%M%S`

then I know what updates when I run source and can spot any omissions. It also gives me the start order and tells me if anything breaks. Like in 10.2 when Apple stopped calling the init Library files by default.

Like I said not too clever but a little trick that helps me.

thatch · 12-02-2002, 04:15 AM

When you say, "...in path", do you mean the infamous ~/Library/init/tcsh/path? When I add it there, exit a terminal.app window and open a new one, I get "PATH_INIT: Command not found.", at the top of the window. Same thing if I put the .TCSHRC_INIT = blah, blah into my ~/.tcshrc.

I'm using OS 10.2.1 and tcsh. And I've noticed that the ~/Library/init/tcsh files aren't really working well except for aliases.mine. It seems to work better, for me, to put everything into ~/.tcshrc and ~/.login, except aliases.

It sure would be great if this would work as you mentioned to spot problems in the sourcing and start order though.

Justin Sane · 12-02-2002, 10:20 AM

I left out the preceding 'setenv' as in:

Code:

setenv ENVIRONMENT_MINE `date +%y%m%d-%H%M%S`

Sorry... ;-)

BTW,
I source my files in ~/Library/init from my .tcshrc using:

Code:

source ~/Library/init/tcsh/path
source ~/Library/init/tcsh/rc.mine
source ~/Library/init/tcsh/environment.mine

Just remember, *.app applicatins (official AppKit GUI applications ) will not read these files which is why Apple uses the plist i.e. ~/.MacOSX/environment.plist. So set anything you want GUI apps to find in that file. Hope that helps.

thatch · 12-03-2002, 02:56 AM

Thanks for the clarification. I see what happens when I add the appropriate environment variable to the various files. But I noticed that all the times for them are the same in tcsh from terminal.app, which is a good thing, I suppose.

Code:

ENVIRONMENT_MINE=021202-233905
RC_MINE=021202-233905
PATH_MINE=021202-233905
TCSHRC_INIT=021202-233905
PATH_INIT=021202-233905

...But in my xterm via windowmaker, it's another story entirely.

Code:

TCSHRC_INIT=021202-234628
ENVIRONMENT_MINE=021202-233905
PATH_INIT=021202-234610
RC_MINE=021202-234628
PATH_MINE=021202-234610

I don't use xterm that much but think it should be the same tcsh environment variables I have set in those various files. I get redundancies in my $INFOPATH and $PATH which may not be that important. And I can't seem to get my ~/.dircolors into xterm unless I add the eval command to my ~/Library/init/tcsh/environments.mine which is called first. But then it breaks terminal.app and its LS_COLORS environment variable.

I will continue to tinker with this in hopes of figuring it out. Any suggestions are most welcome.

sao · 12-03-2002, 01:36 PM

thatch,

(Don't kill me...) of course you tried in your ~/.tcshrc file:

eval `dircolors ~/.dircolors`

Cheers...

thatch · 12-04-2002, 01:05 AM

I've had practically no time for tinkering today, just work. But sao, thanks for your reply. Yes, of course that's the command to put into one of the configuration files and I've tried everything and everyplace I can think of. Currently, I'm satisfied with it in my ~/.login at the end which keeps terminal.app happy but not xterm in windowmaker. If I want to use a configuration that works with xterm, placing the command in my ~/Library/init/tcsh/environments.mine does the job but breaks terminal.app.

I'm fairly convinced that jaguar has mixed some old system and new system attributes for environment configuration, the sourcing and all, and that is why some of this strange behavior. But I have faith it will get ironed out in the next OS release.

Best,

thatch

mnewman · 01-13-2003, 06:37 AM

This has been a most interesting thread and I appreciate the time and effort put into it by the folks who have done the research and who have patiently explained everything.

Tonight I went through and looked at my .login, .xinitrc, .tcshrc and .cshrc files to try and put everything in the right place. After doing so, I find that my path has two copies of:

/usr/X11R6/bin

As far as I can see, it exists only in my .login file.

Where could the second iteration be coming from?

01-13-2003, 07:31 PM

If you have fink installed:

% cat /sw/bin/init.sh | grep PATH | head -1
PATH=/sw/bin:/sw/sbin:$PATH:/usr/X11R6/bin

% cat /sw/bin/init.csh | grep path | head -1
set path = ( /sw/bin /sw/sbin $path /usr/X11R6/bin )

thatch · 01-13-2003, 11:11 PM

mnewman, try removing /usr/X11R6/bin from your ~/.login while it is being sourced from /sw/bin/init.*.

I used to have a problem with redundancies in my tcsh $path on the X window system. But everything was perfect in terminal.app. And I was able to fix it so I would be good in the X system but not in terminal.app.

Then I switched to zsh for my shell and also combo updated 10.2.1 to 10.2.3. I haven't had those redundancies since but I'm not sure if it was the system update or the switch to zsh that fixed it for me.

I described this all in more detail a few post back from here. And even though I couldn't get it exactly the way I wanted in both environments, everything worked just the same, very well. So, having the redundancies at the end of the path really wasn't so bad.

mnewman · 01-14-2003, 02:22 PM

Quote:


	Originally posted by thatch mnewman, try removing /usr/X11R6/bin from your ~/.login while it is being sourced from /sw/bin/init.*.

Oddly, this didn't work. I removed it and still have two /usr/X11R6 in my path.

You're probably right that redundancies don't matter, but I thought it would be an interesting exercise to track it down.

And, Titanium Man, I'm sorry, but I didn't understand your reply to my post. Could you explain, please?

05-10-2002, 02:37 AM	#62
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,237	Hi Timan, If you install VIM - Vi IMproved 6.1, with fink, you also get the GUI version gvim. system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/sw/share/vim" which gvim sw/bin/gvim Package vim In 0.4.0-stable: * Version 6.0-2 In current-stable: * Version 6.0-2 In current-unstable: * Version 6.1-1 Description: Improved version of the editor "vi" VIM adds many of the features that you would expect in an editor: Unlimited undo, syntax coloring, split windows, visual selection, graphical user interface* (read: menus, mouse control, scrollbars, text selection), and much much more. Cheers... PS: Wow Timan, you started this thread, and still is alive and well. Last edited by sao; 05-10-2002 at 02:43 AM.

05-10-2002, 07:44 PM	#67
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	tcsh's quoting can become quite onerous. and the forum's editor strips un-double-quoted backslashes. this should get it... Code: % alias gpid 'ps wwax \| grep "\!" \| grep -v grep \| awk '\\''{print $1}'\\''' be aware of single ticks vs. double quotes; the only thing double quoted is the "\!" also, be aware that you can't rely on this too much for an accurate return. you have to have high confidence that your search arg is completely unique. e.g., try: % gpid ic you wouldn't want to, say, kill, it's return value

11-27-2002, 06:41 PM	#71
Justin Sane Prospect Join Date: Nov 2002 Posts: 2	tracing source order for configs on login Its dirt simple and uninspiringly unclever, but to keep track of everything I add the following line to files: For example in path: PATH_INIT = `date +%y%m%d-%H%M%S` In .tcshrc TCSHRC_INIT = `date +%y%m%d-%H%M%S` then I know what updates when I run source and can spot any omissions. It also gives me the start order and tells me if anything breaks. Like in 10.2 when Apple stopped calling the init Library files by default. Like I said not too clever but a little trick that helps me.

12-02-2002, 04:15 AM	#72
thatch All Star Join Date: Jan 2002 Posts: 534	Please clarify... When you say, "...in path", do you mean the infamous ~/Library/init/tcsh/path? When I add it there, exit a terminal.app window and open a new one, I get "PATH_INIT: Command not found.", at the top of the window. Same thing if I put the .TCSHRC_INIT = blah, blah into my ~/.tcshrc. I'm using OS 10.2.1 and tcsh. And I've noticed that the ~/Library/init/tcsh files aren't really working well except for aliases.mine. It seems to work better, for me, to put everything into ~/.tcshrc and ~/.login, except aliases. It sure would be great if this would work as you mentioned to spot problems in the sourcing and start order though.

12-02-2002, 10:20 AM	#73
Justin Sane Prospect Join Date: Nov 2002 Posts: 2	Clarification I left out the preceding 'setenv' as in: Code: setenv ENVIRONMENT_MINE `date +%y%m%d-%H%M%S` Sorry... ;-) BTW, I source my files in ~/Library/init from my .tcshrc using: Code: source ~/Library/init/tcsh/path source ~/Library/init/tcsh/rc.mine source ~/Library/init/tcsh/environment.mine Just remember, *.app applicatins (official AppKit GUI applications ) will not read these files which is why Apple uses the plist i.e. ~/.MacOSX/environment.plist. So set anything you want GUI apps to find in that file. Hope that helps.

05-10-2002, 02:03 AM	#61
Titanium Man Guest Posts: n/a	Gvim? sao, I tried doing fink list but didn't come up with gvim. Is it unstable still? Wow this post is old. Ok here's my 2 cents: its my ugly ungainly PID getter. It's a Frankenscript that I've thrown together, and while it won't bring about world peace, it was fun researching, and has taught me a lot. In bash, this goes in your .bash_profile, .bashrc, .bash_alias, or in your ear : gpid () { ps ax \| grep "$" \| grep -v grep \| awk '{ print $1 }' ; } then you type gpid Mozilla and you get the PID for Mozilla. In tcsh, I think it'd be something like: alias gpid 'ps ax \| grep "\!" \| grep -v grep \| awk '{ print $1 }'' but I'm not sure, since I haven't been able to to test it. While I'm here, merv (and everyone else), I'm still a little unclear on this .bash_profile vs. .bashrc thing. I understand (I think) that .bashrc is used for non interactive sub process thingies, but is there a need for .bashrc and .bash_profile to be different? Fer example, when I pop open an xterm in Windowmaker, it seems to read from .bashrc, so I'd like all my stuff to be the same as when I'm in Terminal.app. Am I a nut for considering removing .bashrc and replacing it with a symlink to .bash_profile so they'll always be the same and so I don't have to go edit the other when I make changes to the first? Thanks

05-10-2002, 03:05 PM	#63
Titanium Man Guest Posts: n/a	sao, thanks! I got vim, so now to play with it...(good thing I'm off from work today)

05-10-2002, 05:25 PM	#65
Titanium Man Guest Posts: n/a	DING! That was the sound of a lightbulb coming on. The lightbulb over my head. So, .bash_profile is for when logging in, and you can put the "chatty" stuff there, and .bashrc is for other stuff, sub-shells, etc. This is going to be very useful info, merv. Thanks!

05-10-2002, 06:59 PM	#66
vonleigh All Star Join Date: Jan 2002 Posts: 579	Hello, I'm actually interested in just adding a gpid command (for getting pid's). I looked at the example above (for tcsh) that read: gpid 'ps ax \| grep "\!*" \| grep -v grep \| awk '{ print $1 }'' And it didn't work, any other way of doing it? Thanks, Vonleigh

05-10-2002, 08:19 PM	#68
vonleigh All Star Join Date: Jan 2002 Posts: 579	Hello, Thanks MT, you've helped me on too many ocassions already One last question, is there any way to make it ignore capitalization? for example if i do: gpid omni, or gpid Omniweb, it won't find anything because it's "OmniWeb". Thanks, Vonleigh

05-10-2002, 08:27 PM	#69
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	oh, that would be grep -i (gnu's allows --ignore-case) see the grep man pages, right?

05-11-2002, 08:23 AM	#70
vonleigh All Star Join Date: Jan 2002 Posts: 579	Hi mt, Duh! that's so obvious. For some reason I was thinking of some strange solution like the tip about setting upper to lowercase, something really involved. Never thought to just tell grep to ignore case. I'll read the man pages. Vonleigh

12-03-2002, 02:56 AM	#74
thatch All Star Join Date: Jan 2002 Posts: 534	OIC... Thanks for the clarification. I see what happens when I add the appropriate environment variable to the various files. But I noticed that all the times for them are the same in tcsh from terminal.app, which is a good thing, I suppose. Code: ENVIRONMENT_MINE=021202-233905 RC_MINE=021202-233905 PATH_MINE=021202-233905 TCSHRC_INIT=021202-233905 PATH_INIT=021202-233905 ...But in my xterm via windowmaker, it's another story entirely. Code: TCSHRC_INIT=021202-234628 ENVIRONMENT_MINE=021202-233905 PATH_INIT=021202-234610 RC_MINE=021202-234628 PATH_MINE=021202-234610 I don't use xterm that much but think it should be the same tcsh environment variables I have set in those various files. I get redundancies in my $INFOPATH and $PATH which may not be that important. And I can't seem to get my ~/.dircolors into xterm unless I add the eval command to my ~/Library/init/tcsh/environments.mine which is called first. But then it breaks terminal.app and its LS_COLORS environment variable. I will continue to tinker with this in hopes of figuring it out. Any suggestions are most welcome.

12-03-2002, 01:36 PM	#75
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,237	thatch, (Don't kill me...) of course you tried in your ~/.tcshrc file: eval `dircolors ~/.dircolors` Cheers...

12-04-2002, 01:05 AM	#76
thatch All Star Join Date: Jan 2002 Posts: 534	I've had practically no time for tinkering today, just work. But sao, thanks for your reply. Yes, of course that's the command to put into one of the configuration files and I've tried everything and everyplace I can think of. Currently, I'm satisfied with it in my ~/.login at the end which keeps terminal.app happy but not xterm in windowmaker. If I want to use a configuration that works with xterm, placing the command in my ~/Library/init/tcsh/environments.mine does the job but breaks terminal.app. I'm fairly convinced that jaguar has mixed some old system and new system attributes for environment configuration, the sourcing and all, and that is why some of this strange behavior. But I have faith it will get ironed out in the next OS release. Best, thatch

01-13-2003, 06:37 AM	#77
mnewman MVP Join Date: Apr 2002 Location: Korat, Thailand Posts: 2,046	This has been a most interesting thread and I appreciate the time and effort put into it by the folks who have done the research and who have patiently explained everything. Tonight I went through and looked at my .login, .xinitrc, .tcshrc and .cshrc files to try and put everything in the right place. After doing so, I find that my path has two copies of: /usr/X11R6/bin As far as I can see, it exists only in my .login file. Where could the second iteration be coming from?

01-13-2003, 07:31 PM	#78
Titanium Man Guest Posts: n/a	If you have fink installed: % cat /sw/bin/init.sh \| grep PATH \| head -1 PATH=/sw/bin:/sw/sbin:$PATH:/usr/X11R6/bin % cat /sw/bin/init.csh \| grep path \| head -1 set path = ( /sw/bin /sw/sbin $path /usr/X11R6/bin )

01-13-2003, 11:11 PM	#79
thatch All Star Join Date: Jan 2002 Posts: 534	mnewman, try removing /usr/X11R6/bin from your ~/.login while it is being sourced from /sw/bin/init.*. I used to have a problem with redundancies in my tcsh $path on the X window system. But everything was perfect in terminal.app. And I was able to fix it so I would be good in the X system but not in terminal.app. Then I switched to zsh for my shell and also combo updated 10.2.1 to 10.2.3. I haven't had those redundancies since but I'm not sure if it was the system update or the switch to zsh that fixed it for me. I described this all in more detail a few post back from here. And even though I couldn't get it exactly the way I wanted in both environments, everything worked just the same, very well. So, having the redundancies at the end of the path really wasn't so bad.