best way to ensure './' is at beginning of sys.path?

[Marko Rauhamaa]

Grant Edwards <grant.b.edwards at gmail.com>:

> It allows a malicous user to put an evil executable someplace public
> like /tmp and have it executed accidentally. For example, let's say
> this executable file was named "sl" and placed in /tmp.
>
> ------------------------------sl------------------------------
> #!/bin/bash
> rm -rf $HOME
> --------------------------------------------------------------
>
> The next time you are in the /tmp directory looking for something, can
> you guess what happens when you mistype "ls" as "sl"?

There's also the reverse problem. Unix/Linux users are accustomed to
writing their own handy scripts and placing them under ~/bin, where the
default PATH will pick them up. Now, a Linux system has numerous system
commands; on mine:

   $ ls /usr/bin | wc -l
   1790

Nobody can know that most of those commands even exist, so there's a
good possibility that the user's private script accidentally shadows
with one of the system commands.

So if a system command were implemented as a shell script (as many of
them are) that depended on other commands along PATH, it would start
behaving in a random fashion when the user's personal script got
launched accidentally.

Example:
===Begin /usr/bin/c89===================================================
#!/bin/sh
fl="-std=c89"
for opt; do
  case "$opt" in
    -ansi|-std=c89|-std=iso9899:1990) fl="";;
    -std=*) echo "`basename $0` called with non ANSI/ISO C option $opt" >&2
            exit 1;;
  esac
done
exec gcc $fl ${1+"$@"}
===End /usr/bin/c89=====================================================

If I were to write a script called "~/bin/gcc", the "c89" command might
start working in unexpected ways.

A particularly nasty risk is to write a program called "test" and place
it along PATH. The "test" system command is used all over the place.

Now, that's why the distros are careful to place $HOME/bin as the final
entry of PATH; the system commands take precedence over the user's
personal ones. However, the user is free to define the PATH any way they
like.

There's a school of thought that a script should never rely on PATH but
it should spell out the complete path of every command it executes
(including "mv", "cp", "rm" and the like). The problem with that
approach is that different distros have core commands in different
directories.


Marko