Adding folders to PATH

C

colddiver

Registered
How can we modify the path?

The reason I ask is because with Fink, everything is installed in a folder called /sw. That folder now contains:
GNUstep doc fink info libexec sbin src
bin etc include lib man share var

I would like to make the bin and man folders part of my path so that I don't have to cd all the time to execute commands and that I don't get "no entry for XX in the manual" errors anymore.

Thanks,

Colddiver
 
so that I don't have to cd all the time to execute commands

Eeep, nooooo! You are only able to do that because . is already included in your PATH. It makes things easier for DOS people but it's not the correct way to do things, and it's ESPECIALLY dangerous to include . in root's PATH.

To change your PATH, uhhh, just change it. I'd highly recommend removing . from the PATH of any users who are in wheel or listed in sudoers.

man page paths are stored in MANPATH. When MANPATH does not exist in your environment <tt>man</tt> goes by what's in /etc/man.conf. You could either explicitly set MANPATH however you want it for your personal enviroment, or you could edit /etc/man.conf to change it for everyone.
 
I am sorry but I did not understood half of your message... I am not very experienced with unix-alike OS and I am not very familiar with the CLI (although I have learned a lot over the past few weeks).

My current path is this (got this by typing env | grep PATH:
PATH=~/bin/powerpc-apple-macos:/Volumes/Docs/Users/ebeaule/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin
MANPATH=~/man:/usr/local/share/man:/usr/share/man:/usr/X11R6/man

I would like to add
1. /sw/bin
2. /sw/sbin (what is in the sbin directory anyway?)
3. /sw/man

What do I have to type in the CLI or what file do I have to edit for that?

Thanks,

Colddiver, newbie
 
Ok, sorry. I'll try to go step by step and explain what stuff is and why they're they way they are.

How can we modify the path?

In tcsh and csh, do
<tt>setenv PATH [whatever you want it to be]</tt>
Normally this would be in your .profile or .cshrc.

The dot (.) is shorthand for the current working directory. When . is in your PATH you can execute executable files that are in your current working directory without having to specify the full path. That is dangerous. Suppose there's an executable file called `cat' in your home directory and your PATH specifies . before /usr/bin. When you type `cat' in your home directory, ~/cat will run instead of /usr/bin/cat!

Both PATH and MANPATH will use whatever is specified first. For example, if your PATH is /orange:/banana:/apple and you type a command, your shell will first look for it in /orange. If it's not there, it then tries /banana, etc.

Where you specify PATH and MANPATH depends you the shell you're using. tcsh in Mac OS X will go by what's in ~/.profile for PATH and it uses the /etc/man.conf for MANPATH unless you set MANPATH yourself elsewhere (like, in your .profile)

So, to add those new directories to your path, you'd put
<tt>setenv PATH {$PATH}:/sw/bin:/sw/sbin
setenv MANPATH {$MANPATH}:/sw/man</tt>
in your .tcshrc or .profile or whatever you're using.

Alternatively, you could put them in front if you wanted your Fink stuff to take precedence over the other stuff.

sbin is shorthand for the superuser bin. It's a place to keep executables that regular users may not use.
 
Thanks a lot for this... I have been trying to figure that one out for a while. I saved your post for future references!

In my .xinitrc, I was using this:
PATH="$PATH:/sw/bin" ; export PATH

It seemed to work since when I am using a X terminal, I could launch apps that were in the /sw/bin directory without having to cd first (it obviously did nothing for the man).

Now that I made the suggested modification, do I need to keep that line in the .xinitrc? Should I add a new one for the MANPATH?

Thanks again,

Colddiver
 
hate to be a smartass, but this will help:

in the flavour of tcsh that is the default in mac os x, the PATH variable is not a environment variable but a shell variable and should thus be modified with the "set" keyword, and not with "setenv". Using "setenv" would create an environment variable with the same name (PATH) but it would not be searched when looking for a binary. The ".tcshrc" file (should be in your home directory, if not create it) should look like this:

set PATH = {$PATH}:/sw/bin:/sw/sbin

the MANPATH is an environment variable and should be set with:

setenv MANPATH {$MANPATH}:/sw/man

notice that there is no equal sign after the variable name when using setenv. this is quite odd, but blame it on TCSH, not me.

the ".tcshrc" is a useful file. try adding aliases and other nice stuff in it. the same for .shrc if your swinging to that side.

theo hultberg/iconara
 
Thanks for the info, iconara. I didn't realize tcsh did it that way.

On a somewhat-related topic, someone told me that /bin/sh in Mac OS X is actually zsh (!) instead of a plain old bourne shell. Do you know if that's true?

Using zsh for /bin/sh wouldn't break anything (AFAIK) since zsh is meant to be bourne shell compatible, but I don't think it's a good idea. zsh is sort of slow and it's meant to be an interactive shell. Using zsh for /bin/sh might explain why, for example, congfigure scripts seem to run so slowly in MacOS X.
 
after poking around a bit I think you're right... look at this:

[localhost:/bin] theo% ls -l sh zsh
-r-xr-xr-x 1 root wheel 465476 Jul 11 23:56 sh
-rwxr-xr-x 1 root wheel 465476 Jul 11 23:56 zsh

sh and zsh are exactly the same size, this couldn't be a coincidence...


theo hultberg/iconara
 
as any error while using /bin/sh as your login shell will tell you

% /bin/sh
$ mroe hello.c
zsh: mroe: command not found
 
Wow, they really DO use zsh. :eek:

I'm wondering if replacing /bin/sh with a plain old nice, light and fast Bourne shell would help scripts run faster.

Are there any Apple system scripts that DEPEND on zsh? There has got to be a reason why they chose it.
 
Originally posted by Kartoffel
Wow, they really DO use zsh. :eek:

I'm wondering if replacing /bin/sh with a plain old nice, light and fast Bourne shell would help scripts run faster.

Are there any Apple system scripts that DEPEND on zsh? There has got to be a reason why they chose it.
Click to expand...

Because it is more Bourne compatible than ash? Because it is not GPV-ridden like bash? Because Bourne shell is not available without licensing?

FWIW, I would have prefered statically linked ash as /bin/sh; however, some Bourne shell scripts do not run correctly under ash (the ones catching signals behave differently in some cases; sorry, I've ran the tests 2 years ago, so I cannot remember the details)
 
Because it is more Bourne compatible than ash?

It wouldn't be all that big of a project to put together a Bourne compatible shell in-house. But rather than re-inventing the wheel, why not license the Korn shell? It's compatible and quite inexpensive. Most commercial unices use ksh88 as their standard shell. Including the Korn shell would be a big plus for Apple because it's so widely accepted and used in the rest of the industry.

Because it is not GPV-ridden like bash?

I assume you were trying to be funny. :rolleyes: Please take your anti-GNU politics elsewhere. In case you hadn't noticed, the C compiler in Mac OS X is also "GPV-ridden".
 
Originally posted by Kartoffel
It wouldn't be all that big of a project to put together a Bourne compatible shell in-house. But rather than re-inventing the wheel, why not license the Korn shell? It's compatible and quite inexpensive. Most commercial unices use ksh88 as their standard shell. Including the Korn shell would be a big plus for Apple because it's so widely accepted and used in the rest of the industry.
Click to expand...

ksh88 or ksh93 would have been nice, yes. Neither is fully Bourne shell compatible, though, since "nobody could say which syntax does Bourne shell accept, and source was no help either" (or something in that spirit, from the author of rc shell)

Both are way overbloated for a shell which interprets system(3) argument.
 
Originally posted by Kartoffel
Because it is not GPV-ridden like bash?

I assume you were trying to be funny. :rolleyes: Please take your anti-GNU politics elsewhere. In case you hadn't noticed, the C compiler in Mac OS X is also "GPV-ridden".
Click to expand...

Do I, indeed. I can just pray that a decent compiler will appear, in spite of the fact that there is a "free" good-enough one bundled with the system (yes, I want an actually working libstdc++, the one with fully functional and thread safe exceptions, string operations, etc; I also want some more optimization than safely available in -O; call me weird :)
 
You're absolutely right about gcc. It's rough around the edges and lacking some features found in several nicer compilers. :cool:

It's "good enough" for a lot of things, though, and I'm glad the GNU tools are available, if only because it makes it easy to use random Linux and *BSD stuff in OS X.
 
You must log in or register to reply here.
Back
Top