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.

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

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:

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?

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?

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

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 :D

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

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.

Done. Thank you MT.

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?

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.

Yeah, I grok. But see my additional comments:

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

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.

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:

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:

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).

mnewman, c'mon! variables are case sensitive!

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.

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

See what happens when you get old! :confused:

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. :D