Fink 0.5.0a (Final) released - Page 3

thatch · 12-11-2002, 02:33 AM

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

maousse · 12-12-2002, 10:22 AM

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 :

Code:

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

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

mervTormel · 12-12-2002, 10:33 AM

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

sao · 12-12-2002, 10:59 AM

maousse,

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

source ~/.cshrc

It worked fine with me.

Cheers...

maousse · 12-12-2002, 11:46 AM

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 :

Quote:


	.login branches to /usr/share/tcsh/examples/login where the path is set explicitely, so everything that's been sourced before is deleted... If you comment it out #/usr/share/tcsh/examples/login everything works (again) as expected. The question is now what am I missing by bypassing /usr/share/tcsh/examples/login...???

And it works ! I'm asking the same question, but it works...

Thank you again

mervTormel · 12-12-2002, 11:51 AM

it may work, but it is logically wrong.

thatch · 12-12-2002, 04:14 PM

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

mervTormel · 12-12-2002, 04:23 PM

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

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

thatch · 12-12-2002, 05:47 PM

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.

mervTormel · 12-12-2002, 06:04 PM

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.

thatch · 12-12-2002, 06:39 PM

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.

bluehz · 12-13-2002, 02:03 PM

sao - I did the follwoing:

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

and still have maskless curors...

Any other ideas?

justinp · 12-13-2002, 02:33 PM

bluehz:

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

?

bluehz · 12-13-2002, 02:48 PM

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)

sao · 12-13-2002, 04:17 PM

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

bluehz · 12-13-2002, 05:55 PM

Both of those work fine - nice masked cursors.

Quote:


	Originally posted by sao startx -- -fullscreen or startx -- -rootless

sao · 12-14-2002, 04:36 AM

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

12-12-2002, 10:22 AM	#42
maousse Prospect Join Date: Dec 2002 Location: stinky cheese country Posts: 11	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 : Code: source /sw/bin/init.csh source /usr/share/tcsh/examples/rc 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

12-12-2002, 10:33 AM	#43
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	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 __________________ On a clear disk, you can seek forever.

12-12-2002, 11:51 AM	#46
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	it may work, but it is logically wrong. __________________ On a clear disk, you can seek forever.

12-12-2002, 04:14 PM	#47
thatch All Star Join Date: Jan 2002 Posts: 534	...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...

12-12-2002, 04:23 PM	#48
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	here's a thread with some proof of why ~/.login is where to augment the path variable... http://forums.macosxhints.com/showth...&threadid=7721 __________________ On a clear disk, you can seek forever.

12-11-2002, 02:33 AM	#41
thatch All Star Join Date: Jan 2002 Posts: 534	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

12-12-2002, 10:59 AM	#44
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,237	maousse, Or, try by writing in your ~/.tcshrc file: source ~/.cshrc It worked fine with me. Cheers...

12-12-2002, 05:47 PM	#49
thatch All Star Join Date: Jan 2002 Posts: 534	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.

12-12-2002, 06:04 PM	#50
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	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. __________________ On a clear disk, you can seek forever.

12-12-2002, 06:39 PM	#51
thatch All Star Join Date: Jan 2002 Posts: 534	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.

12-13-2002, 02:03 PM	#52
bluehz MVP Join Date: Jan 2002 Posts: 1,562	sao - I did the follwoing: 'fink rebuild xfree86-base' 'fink rebuild xfree86-rootless' and still have maskless curors... Any other ideas?

12-13-2002, 02:33 PM	#53
justinp Triple-A Player Join Date: Mar 2002 Posts: 126	bluehz: http://sourceforge.net/project/shown...ease_id=118483 ?

12-13-2002, 02:48 PM	#54
bluehz MVP Join Date: Jan 2002 Posts: 1,562	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)

12-13-2002, 04:17 PM	#55
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,237	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...

12-14-2002, 04:36 AM	#57
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,237	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...