[lug] Idea for a new tutorial....maybe???

[Tkil]

>>>>> "John" == John Starkey <jstarkey at polaris.umuc.edu> writes:

John> There's a lot of info here. Thanks. ENV wasn't exactly what I
John> was thinking it was but it's along the same lines. Kinda like
John> setting up the desktop, but the shell.

John> What exactly is the PATH? It determines where the shell looks
John> for the explanations of what you type, so it can pass that to
John> the kernel????

no.  PATH is a series of directory paths where the shell will look to
find an executable whose name matches the first word on a command
line.  so, on my box, my PATH setting is:

   /home/tkil/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:\
   /home/tkil/Office51/bin:/usr/openwin/bin:/usr/sbin:/sbin:\
   /usr/games:/usr/local/bin/x

if i type in:

   perl -lwe 'print "hello world!";'

my shell (bash) will look through /home/tkil/bin for something called
"perl" with the executable bit set (man chmod).  next it will try
/usr/local/bin, /bin, and /usr/bin.  since my perl lives in that last
directory, it stops the search and does a fork + exec to launch perl.

since i didn't include an ampersand at the end, the parent shell just
waits for the child to complete.

note that bash does try to be clever by caching results of previous
command lookups.  the "hash" bash built-in controls this (the usual
problem is that i might put a newer version of a tool in
/usr/local/bin, but since the version in /usr/bin got called before, i
have to "rehash" the command lookup cache (hash -r) to get gbash to to
"see" the new version.)

t.

p.s. note that i do not have "." in my path, so bash (and most, if not
     all, unix shells) will *not* find executables in the current
     directory unless i specify "./" to tell the shell where to look.
     
     in particular, this differs from the behavior of MS-DOS and its
     ilk, which always search current directory before looking through
     the PATH [which is semicolon-separated, too, not colon-separated].