justinp, as I had noted earlier, I don't remember ever having to install XDarwin separately from xfree86 and that's because it's integrated into the same install. So, a reinstall is the correct call for it as sao said. Otherwise, glad to hear you added the unstable tree and it's worked out well for you.

sao, I'm glad to help out where I can as you and so many of the other great folks here have done for me. That's part of what makes this forum the best! We sure have some good people here and I appreciate it very much.

Best,

thatch

Hi everybody :)
I've got a very new installation of jaguar, and i wanted to install fink 0.5 . The problem is that i can't figure out how to make it start the way it should.

So, after the package installation, i follow the steps and add "source /sw/bin/init.csh" to my .cshrc file, quit and relaunch Terminal. But, after that, no fink instructions are recognized by the shell. "fink list" for example, etc...

when i open a new terminal window and type first "source /sw/bin/init.csh", no problem, i can play with this fantastic fink in this terminal window....

Obviously, my .cshrc file is not read and interpreted correctly at the shell startup. I have made just one change to the default configuration, i've followed the hint to recover the tcsh functionnalities in jaguar that were in puma (this hint )

So, the problem is i've different instructions in both .cshrc and .tcshrc. I tried to put everything in .cshrc, so that it looks like :But it doesn't work either.... (i get rid of .tcshrc in the same movement)

So, i'm a bit confused, thanks for your help :)

the call to rc is stomping the path after init.csh sets it.

reverse the order of the statements:

source /sw/bin/init.csh
source /usr/share/tcsh/examples/rc

should become:


source /usr/share/tcsh/examples/rc
source /sw/bin/init.csh

maousse,

Or, try by writing in your ~/.tcshrc file:

source ~/.cshrc

It worked fine with me.


Cheers...

Ok, thanks to both of you for your help :)

i've tried both solutions, and none works...
I've cheked up a little closer to the hint page, and finally found a solution in comments (here )
Here's the quote from the original post :
And it works ! I'm asking the same question, but it works... :cool: Thank you again

it may work, but it is logically wrong.

...just wrong on so many levels...
 

This subject is definitely resurfacing every now and again and can be illogical and somewhat unexplainable at times. There are so many end user variables and factors involved and everyone can't be posting their dirty laundry, the reference that Paul makes to the contents of ~/.*rc log files and such in the old resident favorite thread, Best way to set environment?, which is still alive and kicking and has transformed through various OS's and shells and is still probably the best place to continue the discussion if need be.

And why would I be so long windily pointing the focus of this in that direction you might ask? Well, other than my compulsive nature to keep things organized, it is somewhat self serving only because I recently revived that old thread with some of my own chunder, not that I expect any ground breaking revelations to come of it all.

Okay, I'll stop babbling and ease my *ss out the door now... ;)

here's a thread with some proof of why ~/.login is where to augment the path variable...

http://forums.macosxhints.com/showth...&threadid=7721

Yes, I saw that post yesterday and couldn't agree more. And that's where I augment my path variable too. Still, it's a mystery to me why xterm in windowmaker has redundancies when terminal.app is perfect and that xterm doesn't honor all the variables set in ~/.login or ~/.tcshrc.

i saw a good explanation of this some while back somewheres, but for the life of me, i couldn't google it.

does this help? ...

http://supportweb.cs.bham.ac.uk/howto/login/


i think the critter of it is that each new terminal.app window is a login shell window, but only the first xterm is the login window and some jiggery-pokery needs to occur to determine the config for subsequent shells.

i keep looking.

mT, thanks! That's an excellent article and I've not seen it before. It confirms something I had been wondering about with regard to this subject, that there is a such thing as an ~/.xlogin file.

I had asked that question not too long ago, here, but I thought it was wishful thinking on my part since I didn't hear anything to the contrary.

I've got some tinkering to do now to see if I can straighten out the path and dircolors stuff with xterm. Hopefully this will be the missing link that will do the trick. Looking back at this, I should have just tried it since I had thought it was necessary.

sao - I did the follwoing:

'fink rebuild xfree86-base'
'fink rebuild xfree86-rootless'

and still have maskless curors...

Any other ideas?

bluehz:

http://sourceforge.net/project/shown...ease_id=118483

?

justinp - thx - I already updated long ago when it first came out.

I just discovered - if I start X from CLI:

startx -- -rootless -quartz

my cursors are fine.

If I start the XDarwin app - which is my normal MO....that when I get the maskless cursors. So it appears the problem may be within XDarwin app.

FYI - XDarwin v 1.1.1.1 (circa Nov 18, 2002)

Bluehz,

How does it comes out when you start from terminal.app with:

startx -- -fullscreen

or

startx -- -rootless

Prior to 4.2, -quartz was used for fullscreen mode. The -quartz option no longer selects fullscreen mode, but rather uses the default mode set in the preferences.

Read the following info:

http://fink.sourceforge.net/doc/x11/....php#macosx-41


Cheers...

Both of those work fine - nice masked cursors.

bluehz,

Great !

I don't know about the Xdarwin.app, I have the same version as you, and when I start XFree with it, the cursor shows fine.

The code in X since 4.2.1.1 has fixed the black cursor outlines on Mac OS X 10.2.2 as it should be.

Remember that the bug was actually in Quartz in 10.2.1 and earlier. Quartz was initializing automatically that it wasn't supposed to be, according to the API.

Then the problem appeared when they fixed the bug in Quartz, it broke X code that didn't properly initialize the cursor in the first place. So they released X 4.2.1.1 which solved this problem.

It looks like somehow your installation keeps using the old code.


Cheers...