Best way to set environment? - Page 6

mervTormel · 01-18-2003, 02:38 AM

aye. a dot in the path is ill advised. many a trojan horse whinnies thusly. pfbbbbbbbt

well, a few anyhow. it's a known exploit.

thatch · 01-18-2003, 02:42 AM

mnewman, there's another heads up for you. And thanks to mT for confirming that.

mnewman · 01-18-2003, 03:13 AM

OK, except for one thing. All looks well now. Here are my .login, .cshrc, .tcshrc and .xinitrc files along with the env from xterm and the env from terminal.app:

Code:

login:

# Set paths
set path = ( \
   . \
   ~/bin \
   /usr/local/bin /usr/bin /bin \
   /usr/local/sbin /usr/sbin /sbin \
   /Developer/Tools \
	   )
==========

.cshrc:

source /sw/bin/init.csh

==========

.tcshrc

if ( ! $?DISPLAY) then
	setenv DISPLAY :0.0
endif
set autolist

==========

.xinitrc

exec /usr/X11R6/bin/quartz.wm

==========

xterm env:

PWD=/Users/mnewman
QDTEXT_ANTIALIASING=1
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/mnewman:
/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
QDTEXT_MINSIZE=12
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=2097166
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff

==========

terminal.app env:

HOST=Newmans-iBook.local.
HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=.:/Users/mnewman/bin:/usr/local/bin:
/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:
/Developer/Tools
QDTEXT_ANTIALIASING=1
QDTEXT_MINSIZE=12
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=øˇ◊¿
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=Newmans-iBook.local.
DISPLAY=:0.0

The remaining oddity: if I use that .xinitrc, any x11 applications I start are hidden behind the Mac menu bar. If I use the geometry statement to start them up in a better location, they lose their widgets. What causes this?

thatch · 01-18-2003, 03:39 AM

mnewman, you can find info on the remaining oddity in the X11 forum. But I don't use Apple's X11 so I don't know the answer, only that I have seen others talk about those same issues there.

But, I noticed a few things from your files:

First off, you don't need a ~/.cshrc. That sourcing you had there was better off at the end of your ~/.login as you had it before.

Secondly, I'm not seeing everything that should be in your path. Which method did you chose from the README instructions, the system-wide? If so, you should have created /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. And in each of those you should have the proper source line as described.

Thirdly, you should be seeing /sw/bin and /sw/sbin at the beginning of your path and /Developer/Tools and /usr/X11R6/bin at the end of your path in both terminal and xterm.

Lastly, you still need to remove that dot (.) directory line from your path in the ~/.login file. You don't want to have a security risk, right?

mnewman · 01-18-2003, 09:56 PM

I'm becoming hopelessly confused.

I added the .cshrc because I reread the fink documentation and it said it needed that file with that source statement in it.

I did not decide to use the system-wide customization. The only files I have are .cshrc, .tcshrc, .login and .xinitrc.

I removed the dot directory line from the .login file.

I think the path that is in my .login file does not get appended to the path in xterm because xterm does not open a login shell so the .login file doesn't get processed.

I still can't figure out why windows opened in X11 without a geometry statement are hidden behind the Mac menu bar, but using a geoghraphy statement causes the widgets to get lost.

I also have Apple's X11 and fink installed on an iMac. It does not have the hidden/widgets problem. It is only using a .cshrc file and an .xinitrc file. No .login and no .tcshrc. However, note that it too has the redundant path problem in xterm:

Files on the iMac

.cshrc:

source /sw/bin/init.csh

==============================

.xinitrc

source /sw/bin/init.sh
exec /usr/x11R6/bin/quartz-wm

==============================

xterm env:

PWD=/Users/mnewman
USER=mnewman
LANG=en_US
DISPLAY=:0.0
SHLVL=2
SHELL=/bin/tcsh
HOME=/Users/mnewman
PATH=/sw/bin:/sw/sbin:/usr/bin:/bin:
/usr/sbin:/sbin:/Users/mnewman:
/usr/X11R6/bin:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
_=/usr/X11R6/bin/xterm
TERM=xterm
WINDOWID=4194318
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
GROUP=staff
HOST=ChichaiMac.local.
MANPATH=/sw/share/man:/sw/man:
/usr/local/share/man:/usr/local/man:
/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:
/usr/local/share/info:/usr/local/lib/info:
/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5

==============================

terminal.app env:

HOME=/Users/mnewman
SHELL=/bin/tcsh
USER=mnewman
LANG=en_US
PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:
/usr/sbin:/usr/X11R6/bin
__CF_USER_TEXT_ENCODING=0x1F5:0:0
TERM=vt100
TERMCAP=øˇÿ
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=81
LOGNAME=mnewman
HOSTTYPE=macintosh
VENDOR=apple
OSTYPE=darwin
MACHTYPE=powerpc
SHLVL=1
PWD=/Users/mnewman
GROUP=staff
HOST=ChichaiMac.local.
MANPATH=/sw/share/man:/sw/man:
/usr/local/share/man:/usr/local/man:
/usr/share/man:/usr/X11R6/man
INFOPATH=/sw/share/info:/sw/info:
/usr/local/share/info:/usr/local/lib/info:
/usr/local/info:/usr/share/info
PERL5LIB=/sw/lib/perl5

mervTormel · 01-18-2003, 10:01 PM

Quote:


	...xterm does not open a login shell so the .login file doesn't get processed...

correct. xterm is not a login shell, so .login is not sourced.

and you need either .tcshrc or .cshrc, not both. consolidate those.

somewhere, out there, is how to wrangle your startup path based on whether you're a login shell or an xterm. someone may find it soon

if [ ima xterm] then;
do
something special about the path because xterm dint source .login where i keep my path wrangled;
done

mervTormel · 01-18-2003, 10:15 PM

here is some fair treatment of the issue, but i don't like the path wrangling in .blahrc because then the path gets redundant in subshells...

http://www.ee.surrey.ac.uk/FAQ/loginfiles.html

hmm, so, perhaps we need an ifdef include define type dealy.

if [ -z $PATH_SET ] then; do
setenv $PATH_SET=true
setenv $PATH ...;
done

or something like that.

and that will only set the path once no matter how many times you subshell. hmm, is it gonna work for new xterms? test please.

mnewman · 01-18-2003, 10:19 PM

Quote:


	Originally posted by mervTormel and you need either .tcshrc or .cshrc, not both. consolidate those.

Done. Thank you MT.

mnewman · 01-18-2003, 11:48 PM

Quote:


	Originally posted by mervTormel hmm, so, perhaps we need an ifdef include define type dealy. if [ -z $PATH_SET ] then; do setenv $PATH_SET=true setenv $PATH ...; done or something like that. and that will only set the path once no matter how many times you subshell. hmm, is it gonna work for new xterms? test please.

Let me understand. Right now I'm using the path statement in my .login file. Instead, you want to explicity assign a value to the $PATH variable and note that you have done so by creating boolean environment variable to use as a flag.

I assume all this has to go in the .tcshrc file since xterm won't process the .login file?

Sorry if I'm way off, but I haven't played BSD since the late 80's....

....

Thinking about this a little more. If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it? I don't know how to do that in tcsh. I guess it should be done in the .login fiile as that only gets processed once?

mervTormel · 01-19-2003, 12:05 AM

yep. that's exactly it.

this is one technique. i'm still looking for the definitive webpage that discussed this very thing, and i can't seem to craft the magic google cookie to bubble it up.

my above horrorshow coding is brain damaged. should be more like...

if [ -z $PATH_SET ]; then

# wrangle the path

PATH=blah; export PATH
PATH_SET=true; export PATH_SET

fi

this could be put in it's own file and sourced from .blahrc

right, it needs to happen in the .tcshrc file.

it seems to me that there's an if TERM=xterm kinda thing we need to ask in .tcshrc, too.

consider:

login shells source .login/.profile which should source .blahrc

subshells run .blahrc but already have the env var PATH

xterms run .blahrc and don't get the special path wrangling of a login, therefore, need to test and set it if needed.

grok?

so, in your .blahrc file, source ~/.path and path contains the tests to see if the path env var has been set, and do the right thing then, pfbbt, drive on, i believe.

mnewman · 01-19-2003, 12:14 AM

Yeah, I grok. But see my additional comments:

Quote:


	Originally posted by mnewman Thinking about this a little more. If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it? I don't know how to do that in tcsh. I guess it should be done in the .login fiile as that only gets processed once?

And, yeah, there is a TERM=xterm in the X11 environment.

mervTormel · 01-19-2003, 12:21 AM

Quote:


	...If we're going to use the $PATH_SET variable, don't we have to declare it somwhere and then initialize it?...

no, that's the key. check for it's existence, if it don't exist, we need to set the path and init the path_set variable. it's all done in the if [ -z $PATH_SET ] block

mnewman · 01-19-2003, 12:36 AM

Quote:


	Originally posted by mervTormel no, that's the key. check for it's existence, if it don't exist, we need to set the path and init the path_set variable. it's all done in the if [ -z $PATH_SET ] block

I tried it and got this:

PATH_SET: Undefined variable. Because the if statement has to look like this:

if [-z $?PATH_SET] then

See this page:

http://www.cit.gu.edu.au/~anthony/in...sh.startup.faq

About half way down the page he talks about dealing with xterm not inheriting the environment from .cshrc and .login.

I want to study it a bit more so we're not reinventing the wheel here.

mervTormel · 01-19-2003, 12:44 AM

understand that i am in the bash shell here; you may need to craft your if [ foo ] differently, or use the test command...

Code:

$ echo $PATH_SET

$ if [ -z $PATH_SET ]; then echo foo; fi
foo

$ env | grep -i path
MANPATH=/sw/share/man:/sw/man:...
INFOPATH=/sw/share/info:/sw/info:...
PATH=/Users/merv/bin:/sw/bin:/sw/sbin:...

mnewman · 01-19-2003, 01:39 AM

Quote:


	Originally posted by mervTormel understand that i am in the bash shell here; you may need to craft your if [ foo ] differently, or use the test command...

I'm afraid I'm stuck then, because I don't know the syntax. It's been too long. I looked at the tcsh man pages, but it wasn't clear to me how to structure the if..then..else statement.

This is what I'm trying:

Code:

if ( $?PATH_SET ) then      
        echo 'setting path'
        setenv PATH_SET true  
        setenv PATH      :~/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin\
        :/usr/sbin:sbin:/Developer/Tools
        export PATH
        export PATH_SET
else
        echo 'path already set'
endif

Even if I explicitly do an unsetenv on PATH_SET, it doesn't work. Maybe I don't know how to test.

Trying it manually in xterm:

Code:

[Newmans-iBook:~] mnewman% unsetenv path_set
[Newmans-iBook:~] mnewman% if $?path_set echo 'path is set'
[Newmans-iBook:~] mnewman% setenv path_set true
[Newmans-iBook:~] mnewman% if $?path_set echo 'path is set'
path is set
[Newmans-iBook:~] mnewman% unsetenv path_set
[Newmans-iBook:~] mnewman% source .setpath
path already set

01-19-2003, 01:43 AM

This might make life a little less complex:

xterm -ls

The manpage says:

This option indicates that the shell that is
started in the xterm window will be a login shell
(i.e., the first character of argv[0] will be a
dash, indicating to the shell that it should read
the user's .login or .profile).

mervTormel · 01-19-2003, 01:53 AM

mnewman, c'mon! variables are case sensitive!

Code:

% setenv foo bar

% setenv FOO blatz

% printenv | grep -i foo
foo=bar
FOO=blatz

mnewman · 01-19-2003, 01:57 AM

Quote:


	Originally posted by Titanium Man This might make life a little less complex: xterm -ls

Very interesting and it does work. But, /usr/x11R6 is no longer in the path, so we'll have to add that in the .login script.

mnewman · 01-19-2003, 02:00 AM

[QUOTE]Originally posted by mervTormel
mnewman, c'mon! variables are case sensitive!
[code]

See what happens when you get old!

mervTormel · 01-19-2003, 02:10 AM

Quote:


	Originally posted by mnewman See what happens when you get old!

yeah, i know!

but you are on the garden path. just need to test and experiment more on the command line to verify your results. then! commit them to a script.

i condemn you! i mean, i commend you to the eternal fires of... hey, dees don't fit?!

i have olds-heimer's dis-ease too.

01-18-2003, 02:38 AM	#101
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	aye. a dot in the path is ill advised. many a trojan horse whinnies thusly. pfbbbbbbbt well, a few anyhow. it's a known exploit. Last edited by mervTormel; 01-19-2003 at 12:19 AM.

01-19-2003, 12:44 AM	#114
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	understand that i am in the bash shell here; you may need to craft your if [ foo ] differently, or use the test command... Code: $ echo $PATH_SET $ if [ -z $PATH_SET ]; then echo foo; fi foo $ env \| grep -i path MANPATH=/sw/share/man:/sw/man:... INFOPATH=/sw/share/info:/sw/info:... PATH=/Users/merv/bin:/sw/bin:/sw/sbin:...

01-19-2003, 01:53 AM	#117
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	mnewman, c'mon! variables are case sensitive! Code: % setenv foo bar % setenv FOO blatz % printenv \| grep -i foo foo=bar FOO=blatz

01-19-2003, 02:00 AM	#119
mnewman MVP Join Date: Apr 2002 Location: Korat, Thailand Posts: 2,046	[QUOTE]Originally posted by mervTormel mnewman, c'mon! variables are case sensitive! [code] See what happens when you get old! __________________ http://www.mgnewman.com/

01-18-2003, 02:42 AM	#102
thatch All Star Join Date: Jan 2002 Posts: 534	mnewman, there's another heads up for you. And thanks to mT for confirming that.

01-18-2003, 03:39 AM	#104
thatch All Star Join Date: Jan 2002 Posts: 534	mnewman, you can find info on the remaining oddity in the X11 forum. But I don't use Apple's X11 so I don't know the answer, only that I have seen others talk about those same issues there. But, I noticed a few things from your files: First off, you don't need a ~/.cshrc. That sourcing you had there was better off at the end of your ~/.login as you had it before. Secondly, I'm not seeing everything that should be in your path. Which method did you chose from the README instructions, the system-wide? If so, you should have created /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. And in each of those you should have the proper source line as described. Thirdly, you should be seeing /sw/bin and /sw/sbin at the beginning of your path and /Developer/Tools and /usr/X11R6/bin at the end of your path in both terminal and xterm. Lastly, you still need to remove that dot (.) directory line from your path in the ~/.login file. You don't want to have a security risk, right?

01-18-2003, 09:56 PM	#105
mnewman MVP Join Date: Apr 2002 Location: Korat, Thailand Posts: 2,046	I'm becoming hopelessly confused. I added the .cshrc because I reread the fink documentation and it said it needed that file with that source statement in it. I did not decide to use the system-wide customization. The only files I have are .cshrc, .tcshrc, .login and .xinitrc. I removed the dot directory line from the .login file. I think the path that is in my .login file does not get appended to the path in xterm because xterm does not open a login shell so the .login file doesn't get processed. I still can't figure out why windows opened in X11 without a geometry statement are hidden behind the Mac menu bar, but using a geoghraphy statement causes the widgets to get lost. I also have Apple's X11 and fink installed on an iMac. It does not have the hidden/widgets problem. It is only using a .cshrc file and an .xinitrc file. No .login and no .tcshrc. However, note that it too has the redundant path problem in xterm: Files on the iMac .cshrc: source /sw/bin/init.csh ============================== .xinitrc source /sw/bin/init.sh exec /usr/x11R6/bin/quartz-wm ============================== xterm env: PWD=/Users/mnewman USER=mnewman LANG=en_US DISPLAY=:0.0 SHLVL=2 SHELL=/bin/tcsh HOME=/Users/mnewman PATH=/sw/bin:/sw/sbin:/usr/bin:/bin: /usr/sbin:/sbin:/Users/mnewman: /usr/X11R6/bin:/usr/X11R6/bin __CF_USER_TEXT_ENCODING=0x1F5:0:0 _=/usr/X11R6/bin/xterm TERM=xterm WINDOWID=4194318 LOGNAME=mnewman HOSTTYPE=macintosh VENDOR=apple OSTYPE=darwin MACHTYPE=powerpc GROUP=staff HOST=ChichaiMac.local. MANPATH=/sw/share/man:/sw/man: /usr/local/share/man:/usr/local/man: /usr/share/man:/usr/X11R6/man INFOPATH=/sw/share/info:/sw/info: /usr/local/share/info:/usr/local/lib/info: /usr/local/info:/usr/share/info PERL5LIB=/sw/lib/perl5 ============================== terminal.app env: HOME=/Users/mnewman SHELL=/bin/tcsh USER=mnewman LANG=en_US PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin: /usr/sbin:/usr/X11R6/bin __CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=øˇÿ TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=mnewman HOSTTYPE=macintosh VENDOR=apple OSTYPE=darwin MACHTYPE=powerpc SHLVL=1 PWD=/Users/mnewman GROUP=staff HOST=ChichaiMac.local. MANPATH=/sw/share/man:/sw/man: /usr/local/share/man:/usr/local/man: /usr/share/man:/usr/X11R6/man INFOPATH=/sw/share/info:/sw/info: /usr/local/share/info:/usr/local/lib/info: /usr/local/info:/usr/share/info PERL5LIB=/sw/lib/perl5

01-18-2003, 10:15 PM	#107
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	here is some fair treatment of the issue, but i don't like the path wrangling in .blahrc because then the path gets redundant in subshells... http://www.ee.surrey.ac.uk/FAQ/loginfiles.html hmm, so, perhaps we need an ifdef include define type dealy. if [ -z $PATH_SET ] then; do setenv $PATH_SET=true setenv $PATH ...; done or something like that. and that will only set the path once no matter how many times you subshell. hmm, is it gonna work for new xterms? test please.

01-19-2003, 12:05 AM	#110
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	yep. that's exactly it. this is one technique. i'm still looking for the definitive webpage that discussed this very thing, and i can't seem to craft the magic google cookie to bubble it up. my above horrorshow coding is brain damaged. should be more like... if [ -z $PATH_SET ]; then # wrangle the path PATH=blah; export PATH PATH_SET=true; export PATH_SET fi this could be put in it's own file and sourced from .blahrc right, it needs to happen in the .tcshrc file. it seems to me that there's an if TERM=xterm kinda thing we need to ask in .tcshrc, too. consider: login shells source .login/.profile which should source .blahrc subshells run .blahrc but already have the env var PATH xterms run .blahrc and don't get the special path wrangling of a login, therefore, need to test and set it if needed. grok? so, in your .blahrc file, source ~/.path and path contains the tests to see if the path env var has been set, and do the right thing then, pfbbt, drive on, i believe.

01-19-2003, 01:43 AM	#116
Titanium Man Guest Posts: n/a	This might make life a little less complex: xterm -ls The manpage says: This option indicates that the shell that is started in the xterm window will be a login shell (i.e., the first character of argv[0] will be a dash, indicating to the shell that it should read the user's .login or .profile).