>> I?m trying to learn how to program C++ on linux. I started with the
>> standard ?hello world? script. I compiled with the command;
>> g++ -o hello hello.cc
>> Everything seem to go well, but when I try to run:
>> There was the following error:
>> Bash: hello command not found.
> Probably you have a very simple problem:
> the current directory is not in your search path.
> You may either try to start the program with:
> This tells the shell to look for 'hello' in
> the current working directory '.'
> Or/and you add the current directory to your
> standard-search path (where the shell looks for
> export PATH=$PATH:.
> appends the current directory '.' to the list of
> directories already in the environment-variable '$PATH'.
> You can check this with
> echo $PATH
> You should ** not ** add . to PATH as root, as
> this might impse security risks.
this applies to user accounts too. Think of SUID programms
that could be in some path you don't know.
It is best to not include . in you PATH environmetn variable
but allways run a program in your current working directory
by typing its absolute or relative path which is ./program
when the program lays in current working directory (as printed
When you append . to your PATH-environment you could also
run into the following problem:
$ cat test.c
$ gcc -o test test.c
you expected to run your newly generated test program which
should output hello world on the terminal.
But what you ran by accident was the unix test command,
which on linux systems (sorry all bash shells) is a
shell built in.
This could happen with quite a lot executables that are
on the system or commands included in the shell.
I think it is best to get used to ./program so you don't
get confused by other programms.
Somebody else might say, that you could put . in the beginning
of the PATH environment so that the current directoy is
searched first, but that does not apply to shell built-ins.
Also it brings some new problems with it.
Think of this situation:
Some other user puts a little program in your homedirectory
or some directoy you sometimes visit on the system
called ls. This program will be able to do what ever it wants
just when you type ls to list the directories contents.
So I'ld really say to simply not put . in the PATH variable,
and to know that it is not in there. This makes your use
of the system more safe.
To the OP:
The real problem might be that you had a program called hello
in some other directory before. Now bash builds up a so called
hash table where it memorizes wher to find programs, so it does
not have to search for the program everytime it is called.
If you move the executable to some other place the shell
gets the string entered at the commandline looks thru its
hashtable and finds it in there. Now it wants to execvp()
the associated executable (with its absolute path). But execvp()
will return, because it cannot find the executable at the given
path. So the shell will say "file or directory does not exist"
or "command not found".
You can flush the hash table with bash's builtin command
"hash -r". Please look this up in bash's man page section
SHELL BUILTIN COMMANDS.
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond