Modifying tcsh path the proper way.

[hschickel]

I'm trying to modify my path in a secure way as instructed in the readme at:
/usr/share/init/tcsh/README.

[localhost:share/init/tcsh] hs2admin% more readme
This directory contains some useful tcsh files.

In order to use this configuration:

echo "source /usr/share/init/tcsh/rc" > ~/.tcshrc
echo "source /usr/share/init/tcsh/login" > ~/.login
echo "source /usr/share/init/tcsh/logout" > ~/.logout

To do this system-wide, do the same instead to /etc/csh.cshrc,
/etc/csh.login, and /etc/csh.logout.

In order to customize tcsh:

mkdir ~/Library/init/tcsh

and create the following files there as necessary:

aliases.mine - shell aliases
completions.mine - completions
environment.mine - environment
rc.mine - run commands
path - command search path

See the corresponding file in /usr/share/init/tcsh for more information about
the role of each file. You can easily extend or override the configuration
provided by the default file. For example, you can add more aliases by adding
the appropriate commands in aliases.mine.

-Fred
Massachusetts Institute of Technology
tritan@mit.edu


I've created the files ~/.tcshrc, ~/.login, ~/.logout and they are sourced as per the readme. I further created the directory ~/Library/init/tcsh and placed a file called path inside it with the path to the devtools as follows: /Developer/Tools . I get the following output when I start a new terminal and try CpMac (a developer tool):

Welcome to Darwin!
/Developer/Tools/: Permission denied.
/Developer/Tools/: Permission denied.
[localhost:~] hs2admin% CpMac
CpMac: Command not found.
[localhost:~] hs2admin% /Developer/Tools/CpMac
usage: /Developer/Tools/CpMac [-r] [-p] [-mac] <source-path> <dest-path>
/Developer/Tools/CpMac [-r] [-p] [-mac] <source-path>... <dest-dir>
[localhost:~] hs2admin%

As you can see, something is amiss. The devtools are still there but they are not being seen in my path. They work fine if I use the long way to get to them. What am I doing wrong?

Please note: I'm trying to avoid directly modifying the /usr/share/init/tcsh/login file as per the issues discussed in this thread (http://forums.osxhints.com/showthread.php?s=&threadid=234) (ie adding files writable by other than root to roots path.) I'm also looking for more than just: set path = ($path /Developer/Tools) as this seems to only affect the current terminal session.

Thanks,
Hugh

[mervTormel]

hey hugh,

you show me your perms and i'll show you mine [;=

% ll -d /Developer/
drwxrwxr-x 13 root admin 398 Jan 3 15:23 /Developer//

% ll -d /Developer/Tools/
drwxrwxr-x 20 root admin 636 Jan 3 15:30 /Developer/Tools//

what group is your username in?

% id
uid=501(merv) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

i don't exactly like the group write in /Devo, but i'm not going to change it yet.

now then, you _should_ avoid directly modifying the /usr/share/init/tcsh/login

--
also looking for more than just: set path = ($path /Developer/Tools) as this seems to only affect the current terminal session.
--

No, the development environment should only be set up per terminal session. What if you wanted to test a product as user Sally Punchclock? You would want sally's environment not to have any access to /developer and you would sudo/su sally and test your product under the guise of simple user. we call this 'sandboxing'

Grok? We could start a treatise on a Devo->QA->Production environment if it's interesting to anybody.

[hschickel]

Merv - you're in the majors now!!! How did I know you would come to the rescue again? LOL

Welcome to Darwin!
[localhost:~] hs2admin% ll -d /Developer
drwxrwxr-x 11 root admin 330 Nov 10 01:20 /Developer
[localhost:~] hs2admin% ll -d /Developer/Tools
drwxrwxr-x 20 root admin 636 Jan 28 09:01 /Developer/Tools
[localhost:~] hs2admin% id
uid=501(hs2admin) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)
[localhost:~] hs2admin%

I believe those are all set properly. In any case, all users have x permission for the devtools and I can use them with the long path with no problems. Any thoughts?

No, the development environment should only be set up per terminal session. What if you wanted to test a product as user Sally Punchclock? You would want sally's environment not to have any access to /developer and you would sudo/su sally and test your product under the guise of simple user. we call this 'sandboxing'

Perhaps I'm wrong - but won't adding the path to my ~/Library/init/tcsh/path only affect my path? Can't I su to or login as another user and not let them have access?

Thanks,
Hugh

[griffman]

Here's the line I used in the "path" file to add the Developer Tools, and it seems to have worked:% cat path
setenv PATH ${PATH}:/Developer/Tools:/Developer/ApplicationsI now have the Dev Tools in my path. Forgive me if this is the syntax you used in "path", but you didn't state, so I thought I'd start with the obvious :-).

-rob.

[hschickel]

Hey Rob,

Perhaps I'm doing something wrong - but that command only adds to the path through the current terminal session. It expires (on my machine) when I launch a new terminal.

The file I added to my path was as follows:
/Developer/Tools
in the file ~/Library/init/tcsh/path as per the README referenced above. This works - but the permissions are screwy. This is the part I cannot figure out.

Thanks,
Hugh

[mervTormel]

thanks, rob. that is rather obvious, but if you use tcsh, your env PATH may be out of sync with your shell variable path.

tcsh auto exports the value of shell variable path to env PATH, so i think you might want to be setting path in your ../tcsh/path

# What is a cooler way to set my path with tcsh?
# If you want to make sure only directories that exist are in your path, you can use something like this:

echo ""
echo -n "wrangling path... "

set d=($path)
set p=()
foreach x ( $d )
if (-d $x ) set p=( $p $x )
end
set path = ( $p )
unset p d

echo $path
echo " $PATH"


If you just want to add a directory to your path on the command line, with (t)csh, you can use:

set path = ( $path /tmp )

With a Bourne shell syntax you can use:

PATH="$PATH:/tmp" ; export PATH

--
now back to our regularly scheduled program...

hugh, i need to re-read the posts and investigate. i'll comment some more later.

[griffman]

The above line is the sole contents of my "path" file in ~/Library/init/tcsh, so it loads each time I open a new Terminal window. I just used "cat" to show the output.

I guess I'm confused; I thought I was doing it the way OS X wanted - by using a "path" file in ~/Library/init/tcsh. Merv, why won't this work??

-rob.

[hschickel]

Rob,

I misunderstood the proper syntax of the path file.

By using your command as the ~/Library/init/tcsh/path file the problem was solved.

Thank you,
Hugh

Edit - this of course brings up a question.

Why does the first way show up but give a permissions error?

[mervTormel]

rob,

urp, sorry for the confusion, loss of focus, the env variable 'PATH' and the shell variable 'path' are kept in sync automagically, in tcsh. you are doing it right, obviously, and it does work. i thougt it was a one way sync 'path'->'PATH'

hugh,

what i suspect is that ~/.tcshrc or .login may be possibly stepping on your path? or thwarting your call to ~/lib.../tcsh/path ?

i had a lot of trouble with consistent new shell windows when i had those files in my $HOME. so i rm'd them. now, i use the ~/lib.../tcsh/*.mine files exclusively. it simplified my startup.

check that out by investigating those $HOME tcsh startup files, possibly renaming them (to save them) and see if a new terminal window has the path of your first shell window.

[hschickel]

Merv,

I looked a little more closely at the ~/.login, ~/.logout and ~/.tcshrc files. I believe the are precluded by the system wide /etc/csh.cshrc,
/etc/csh.login and /etc/csh.logout files. In any case, I rm'd 'em.

The real key is in the ~/Library/init/tcsh directory. My issue with ~/Library/init/tcsh/path was syntax. I used /Developer/Tools when I should have used set path = ($path /Developer/Tools) or
setenv PATH ${PATH}:/Developer/Tools. I'm not sure what the difference is exactly so I used the first (it was simpler). With my track record here that is probably a huge security hole though. :)

Thanks,
Hugh

[michaelfr]

I've reviewed the posts here, as well as the READ ME file for customizing my environment.

The only one I really want to customize is the path and classpath variables.

So I entered the following into ~/Library/init/tcsh/path:

##
# ~/Library/init/tcsh/path
##
# Michael Frankel
# Wizard Consulting Group
# 27 MAR 2002
##
# Add PATH for Apple Developer Tools
#
set path = ($path /Developer/Tools)
#
# Add CLASSPATH for JDBC software
#
set classpath = ($classpath /Users/michaelf/Library/Java/mm.mysql.jdbc-1.2c)
#
##
# End of ~/Library/init/tsch/path
##

However, when I open up Terminal, this is what I see:

Missing }.
Missing }.
}: Command not found.
Missing }.
red255green255blue255: Command not found.
}: Command not found.
margl1440margr1440vieww13920viewh8640viewkind0: Command not found.
pardtx560tx1120tx1680tx2240tx2800tx3360tx3920tx4480tx5040tx5600tx6160tx6720qlqnatural: Command not found.

I have NO idea what this means. Any ideas?

Thanks...

[bakaDeshi]

set path = ($path /Developer/Tools)

should be CAPS
set PATH = ($PATH /Developer/Tools)


set classpath = ($classpath /Users/michaelf/Library/Java/mm.mysql.jdbc-1.2c)

CAPS
set CLASSPATH = ($CLASSPATH /Users/.../Java
I think you stop at the directory where your packages start. not sure though.

-bakaDeshi

[mervTormel]

Originally posted by bakaDeshi

----
set path = ($path /Developer/Tools)
----

should be CAPS
set PATH = ($PATH /Developer/Tools)


no, the lowercase form is proper for the tcsh set shell variable command.

the tcsh setenv command would use uppercase PATH to set the environment variable.

tcsh maintains equivalent values with the shell variable $path and the environment variable $PATH

$path is a whitespace delimited list of dirs

$PATH is a colon delimited list of dirs

% echo $path
/Users/merv/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin

% echo $PATH
/Users/merv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

[bakaDeshi]

Sure is. thanks for the correction. :o

Unix is case sensitive. Apparently, not everywhere. :confused:
Does this only apply to environment variables in setting your defaults or are there other places where I can use lowercase?

Some consistency would be nice, although I like typing "echo $path" in lowercase without switching to uppercase.

Learned something new today.:D

[mervTormel]

unix is case sensitive. everywhere. you can use any case you want. eVeN StRaNgE CaSe. by convention, environment variables are uppercase; they are not required to be. the best approach is to be consistent with your notation, and to play by the rules that convention dictates.

iForOneUseHungarianNotation. itsEasyOnTheEyes andUsesTheMinimumCharactersAndCaseTwiddlings

tcsh just happens to have a shell variable called path that is space delimited and changes to its value are reflected in its environment variable PATH. and visa versa. i don't know why. it's bizarre.

except in the code:

% set PATH = ($PATH /Developer/Tools)

% echo $PATH
/Users/merv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Tools

% echo $path
/Users/merv/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin

the variable parity doesn't cascade. also, no error is reported.