On mardi, mars 18, 2003, at 17:36 Europe/Paris, David R. Morrison wrote:
Yet another way this can go bad (that I hadn't thought of) is
described in:
http://www.mail-archive.com/[EMAIL PROTECTED]/
msg06499.html
In this case, the .login explicitly sets the path, overwriting what was
already don
As per the documentation, how about this:
1) create/edit ~/.cshrc
2) If users followed the setup under
/usr/share/tcsh/examples/README
which seems like a common thing to do, they should source ~/.cshrc in
~/Library/init/tcsh/path
3) Otherwise, they should check whether there's a .tcshrc pre
Yet another way this can go bad (that I hadn't thought of) is described in:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg06499.html
In this case, the .login explicitly sets the path, overwriting what was
already done in .tcshrc or .cshrc.
So, it's going to be difficult to get this set up in
Am Freitag, 14.03.03 um 21:13 Uhr schrieb David R. Morrison:
[...]
case yes) check if "source %p/sw/init.csh" is already in the
.tcshrc
How exactly could this be done? Considering that scripts can include
arbitrary other scripts? Also, the "source" statement could b
On Monday, March 17, 2003, at 02:38 PM, Max Horn wrote:
Am Montag, 17.03.03 um 23:04 Uhr schrieb David R. Morrison:
[SNIP]
One thing which Ben Reed and I were talking about in this regard is
that
it would be good to put in a little check in /sw/bin/init.csh to stop
it from getting loaded twice
Hi Martin. Thanks for making the script. A couple of comments:
1) If the user is running csh not tcsh and doesn't have any dotfiles,
then I think we want to create .cshrc NOT .tcshrc. Also, if
there are no existing dotfiles then creating .cshrc is OK for
tcsh users as well. And
Max Horn wrote:
[]
If you are trying to get to the angle that the people who will want to
use our tool will not have a complex .tcshrc / .cshrc - then I will
disagree. Yes, 99% of them won't have one, but I am willing to bet high
amounts of money that there are those who have a complex .cshrc. E
Am Montag, 17.03.03 um 23:04 Uhr schrieb David R. Morrison:
Hi Max.
Well, my idea is that we do something fairly sensible, but then offer
the
user the chance to see the file we changed and edit it some more if
they
want.
Yeah I understood that was your intention.
This non-CLI setup is mainly
Hi Max.
Well, my idea is that we do something fairly sensible, but then offer the
user the chance to see the file we changed and edit it some more if they
want.
This non-CLI setup is mainly intended for people who haven't used the
command line much and so will likely only have the default setup.
On Friday, March 14, 2003, at 03:13 PM, David R. Morrison wrote:
Anybody want to suggest a tool for creating this .app
painlessly?
-- Dave
It could easily be done in Cocoa.
---
This SF.net email is sponsored by:Crypto Challenge is now open
On Friday, March 14, 2003, at 12:13 PM, David R. Morrison wrote:
Anything missing? Anybody want to suggest a tool for creating this
.app
painlessly?
Cocoa, i think... :)
Or perl's Mac::Carbon also could probably do the trick. The OS X port
is relatively new, but i'm sure it is quite capable
I thought the X11 PATH stuff gets set in init.(c)sh
There is an issue with Apple X11, but I don't think we can fix it here:
Apple X11 doesn't honor the fink environment, and you have to add
"source /sw/bin/init.sh" to .xinitrc in order to run fink-installed
applications, e.g. a window manager. S
Actually, something may be missing here: getting paths straight for X11.
I'm not sure what the best procedure is for that these days, or if it
is even the same for Apple's X11.app and the XFree86 version, but it
would be good to allow that to be handled automatically as well.
-- Dave
-
Dear Fink developers,
I propose a new strategy for having users initialize their Fink installations.
We should have a little Aqua app, which at the moment I'm calling
NewFinkUser.app, which guides a user through setting up Fink on their
account. The app should be run by the binary installer so th
14 matches
Mail list logo
