> >hey everyone. I'm having some problems with my new linux install. the
> >install itself seemed to go through without too much trouble, but then
> >things begin to go downhill a bit. my machine will start up and all,
> >but he seems to be rather picky about what he wants to run. things like
> >telnet and tar and pine and such seem to work fine, but just about
> >anything else just won't go. I'll enter the name of an executable file,
> >and i get back "Bash: foo: command not found" or something similar.
> >it's not a case sensitivity problem, I'm not that much of a newbie.
> >:-) anyway, any help would be appreciated. oh yes, I almost forgot.
> >could anyone advise on the editor commands in tin? i gave up looking
> >for how to send (or even finding any help whatsoever) that I just went
> >and used a friend's wintel box to post this. thanks in advance.
> most commands needed by root are stored in /sbin or /usr/sbin.
> these are not in $path
> So you must type the whole path to the command
> to find a command type whereis command
> HTH :)
> Red Hat Linux release 6.0 (Hedwig)
> Kernel 2.2.5-15
> 10:17pm up 20 min, 2 users, load average: 0.10, 0.29, 0.32
> Tue Apr 4 22:17:32 CEST 2000
As an alternative to typing in the entire path for each command,
you may set up an environment variable called path or PATH, and
the means to do this vary with the shell you are using.
I typically use the GNU Bourne-Again Shell (bash) which is aliased to
the Bourne Shell (sh), since bash is merely an extended version of sh.
In my setup, each user has a dot file called .bashrc, where I set up most
of my environment (e.g., LD_LIBRARY_PATH, PATH, CLASSPATH,
etc.) Example entries are:
This is just a small example of the path env var. There are a number
of other common ones, and in Unix/Linux, many applications use
env vars to control the application state, pass parameters, etc.
Note that you may concatenate the parts of the variable and then
export it to the environment as I have done above, or you may
export the concatenation element by element with:
export PATH= .
and so on, eliminating the need for the export at the end of the list.
If you use the C-shell, the syntax is different.
Note that I put a dot in as one of the path entries. That entry translates
to the current working directory, which will allow you to invoke an
executable in the derectory you are currently logged into, without
either putting the dot-slash ("./") or some more fullsome path
name in front.
There is nothing magic about the organization shown above. It is just
a method of organizing items in my .bashrc such that I don't lose my
mind. I have perhaps a hundred environment variables, and by commenting
the sections, (comments start with a pound symbol) and using the
above method of dedicating one directory to a line, I can edit in changes
rapidly while still holding down the error rate.
There is one other dot file, called .bash_profile, which some folks use
to hold their aliases and environment variable settings. I prefer .bashrc,
because it is sourced each shell that you throw, whereas .bash_profile
is sourced only when you login.
Good Luck with your path and dot files.