./

[cdevers at pobox.com (Chris Devers)]

On Mon, 10 Nov 2003, eric wrote:

> hey. it's not easy teaching yourself linux.  here's one for somebody
> who's bored tonight...  what does ./ mean?
> if i cd to /usr/sbin and then type tripwire, nothing happens, but if i
> type ./tripwire off we go.  why?

It's a path hint. In most/all Unix filesystems -- as well as DOS/FAT --
'.' is shorthand for the current directory, and '..' is shorthand for the
directory one level up from the current directory. As a parallel, '~' is
shorthand for your home dir.

So, when you type "./foo", the shell expands that "." to whatever the
current working directory is. If you're in /usr/local/bin, then that is
what '.' would expand to.

The reason you have to type this sometimes has to do with your shell's
$PATH environment variable. For any command you type that is not specified
with a full path -- such as /usr/local/bin/foo -- the shell searches for
that command among the set of available programs in the directories that
are mentioned in your $PATH variable.

So for example, one one account my $PATH is as follows:

   $ echo $PATH
   /Users/cdevers/bin:/sw/bin:/usr/local/bin::/usr/bin:/usr/X11R6/bin:/bin

To see how this works in practice, assume I type 'zgrep foo /tmp/bar.gz'.
The first place my shell would look for the command is in my ~/bin
directory.  If there isn't one there, it'll look in the next directory
mentioned -- Fink's bin directory at /sw/bin. I've got the GNU version of
gzip installed through Fink, so I have a /sw/bin/zgrep command -- that's
what would be used. If I didn't have that package/file, thenthe shell
would keep working down the list until it got to /usr/bin, where Apple's
copy of /usr/bin/zgrep would be found and used.

Note though that "." doesn't show up anywhere in my $PATH. This is a
security consideration. It used to be common to prefix $PATH with '.', so
that `echo $PATH` would begin ".:/usr/local/bin:..." etc. But keeping the
current directory out of your path protects you from situations where an
untrusted user puts a copy of a program with behavior defined by them into
a directory where you might be working. So for example if someone breaks
into your web server somehow, and uploads a malicious file named 'vi' to
your /usr/local/apache/htdocs, then the next time you try to do this:

    $ cd /usr/local/apache/htdocs
    $ vi index.html

You would end up running that person's program over your index file,
rather than the editor you were probably expecting. That program can do
anything -- attempt to do a `rm -rf /`, change your password, create a
backdoor for them to get in, etc. If sneaky, it might then do what it
seemed like it should have done -- open up vi in this case -- so that you
might not even realize the damage until it was too late.


So. If you use commands in /usr/sbin a lot, you may want to consider
adding that directory to your $PATH, by editing the relevant login scripts
(e.g. ~/.profile, ~/.bashrc, or ~/.tcshrc). Somewhere in there should be a
line declaring your $PATH. You can either edited that line, or do
something like this:

    PATH=$PATH:/usr/sbin

(with slightly different syntax for tcsh). On the other hand, sbin
directories are generally reserved for commands that should only be run by
a priviliged user, so leaving them out of your path might be safe anyway.


Make sense?



-- 
Chris Devers