OK thank you very much for your help ! it works !
actually, you need to understand what is going on....
(and people can correct me, etc).
When you make:
test.sh containt
PATH=${PATH}:/new/path/component
export PATH
and then you run this... your new PATH *is* being set.... in that script... in the "environment" for that
script -- and for the environment in the children of that script... but, when the script ends... that
environment ends.
If you want that command to affect your *current* environment -- you can consider your current
environment the "parent" and that script the "child" ... and you'll probably come across it said that
children can't modify the environment of their parent -- and although this isn't entirely true, it's
mostly good enough for now.
So, in your current environment, you need to update your path.... so, instead of creating a new environment
by running a shell and executing that script, since you're already IN a shell, just load that script into your
current environment --
. /path/to/test.sh
etc.
source is [t]csh .. and I don't know if bash/ksh have it -- the ksh that I am use to does not.
sh has traditionally used "."
You may also see programs that will do things like this (ie: check the start up of any unix/linux box)
#!/bin/sh
. /path/to/ENV
command1
command2
command3
The idea there is that someone puts commands in the "ENV" that make things work -- but then that
environment is needed in many different locations -- and instead of copying it each time (which would work) or calling the script like you did before "/full/path/to/test.sh" (child) which would NOT affect the
current (or parent) environment, the "." is used.
The different is the "relative" environment. Current (parent) or new (child) -- where the child can not
change the parent's env (for the most part, this should be remembered).
most all unix problems/issues come from "path" or "permissions" ... although the example above probably
isn't either, I thought it was woth mentioning (also, it's just my opinion).
Scott
