On Wed, Oct 13, 1999 at 02:08:41AM +0000 or thereabouts, [EMAIL PROTECTED] wrote:
> JoAnn Elliott wrote:
> 
> > well, acutally
> > used the ./ns-install as the instructions did not tell me to do a ./ before
> > it, but "just this girl" said to use that and it worked. 
> 
> Ok. For the budding backyard mechanics:
> ./something
> means 'in this directory, run the file something'.

Argh, yes, this is definitely a frequent stumbling point.

> Why is this necessary?
> 
> In your shell (I'm hoping you know what a shell is. Quote this to the list 
> and say 'I don't!' if you don't. Actually, if you don't understand any of 
> this explanation, quote it back to the list and ask!)
> 
> In your shell, you have environment variables. These set all kinds of 
> things the system needs to know about how you want your system to run.
> One of them is the 'path'. This is basically 'where do I look for programs'.

If you want to know what yours is, incidentally, and you're running
bash, type
        echo $PATH

That'll list all the things your shell considers to be on your path.
Another useful thing to know is that your shell looks through those in 
order, from left to right. An example is this: 

I had two copies of Lynx, one built with SSL (this is one of the ways
of making its security stronger). Lynx normally lives in /usr/bin, and
I put the second one in /usr/local/bin. I got bored of having to tell
the machine, "when I say Lynx, I want the second one". Instead of
using the alias command (someone else can explain that, I rarely use
it :)) to do this, I changed my path so that my shell looks in 
/usr/local/bin first, and then /usr/bin. So I just type lynx now and 
I get the one which I prefer. My friends, however, haven't changed
their paths, and they get the normal one. 

> The root shell DOES NOT include "./". Very deliberately.
> Why?
> Because you /don't/ want to be in some smart-aleck user's directory,
> run 'cd' or some other innocuous process, and have a program run that 
> sets - say  - resets root's password to something the user knows then
> runs cd with your argument.

There used to be a school of thought which suggested that you were
safe to have dot in your path if it was at the end (the right :)) of
it, because then, if you typed 'ls' in someone's directory, you'd
get the results of /bin/ls because /bin was before the dot. I don't
know whether people still suggest that now? I do know that lots of 
people thought that this was a compromise that still wasn't safe.

> Other users are presumed to not control anything vital, and to be 
> unlikely to be hanging around in someone else's directories. :)

On the system I first encountered unix on, we had all sorts of stuff
in people's home directories. Anything from interesting scripts they'd
written to complete bulletin boards!  So you were very likely to be in 
other people's directories and open to potential danger on that one. 

So this business of dot on one's path, and learning to remove it
(which you can do by editing your .bash_profile in bash, and I think
your .login in csh?) was quite important there. And it was an excellent
habit to get into, especially as once I started getting accounts
elsewhere, I always started by removing the dot from my path. 

Telsa

************
[EMAIL PROTECTED]   http://www.linuxchix.org

Reply via email to