I was compiling and running C programs on my linux machine (Ubuntu) about a couple weeks ago. Now, I can compile C programs, but not run them...the only thing diffrent about the machine is that i've updated ubuntu. The programs run off of other machines, but when I attempt to run one on mine I get "command not found" or simply nothing happens at all for other programs. Is there any other way to try and run these programs other than just typing the name of what I compiled them as? I don't have internet access for my machine at the moment (using a diffrent one), but I guess i'll force an update when i do unless somebody has a suggestion
Nothing happens, in a simple hello world program for stdout
$>gcc -Wall test.c -o test
And for a more complicated program, I get
bash: test: command not found
Try "./test" - perhaps current directory isn't part of your path to executables.
but more importantly, if you are using Unix/Linux or using a "unix shell" based shell, don't call your application test, as it's a shell-command called test that checks for properties of files (e.g. if test -f blah.txt ... will test if there is a "regular file called blah.txt"). Doing this is a bad thing.
On linux, when you simply type a command in the terminal, the shell will automatically try and look for it in the paths specified in the PATH environment variable - You can try doing "set | grep PATH"
Anyway, when running programs local to your directory, you have to use ./program_name.
The dot means that it's in the current working directory(As opposed to two dots(..) meaning the parent directory) and the / is to denote it's in that directory.
Test is actually a program in ubuntu. You can try doing "which test", and you'll find out it's located in /usr/bin/test. If you run it without any arguments, nothing happens. This is why it seemed like the first program called test seemed to run, but the other(Which must've been named something other than test, even though it's called that your example) doesn't, because you didn't specify the ./.
"echo $PATH" will also show the current path.
If you want to add "current directory" to the search-path, try something like this:
Note that the curly brackets are necessary here, as otherwise the shell will not necessrily know how to separate the environment variable PATH from the bits you're adding to the path. It is optional to use curly braces when dealing with variables where there are white-spaces delimiting the name.
I don't think that adding dot-slash to your environment path is a capital idea. You should just type it yourself, or work "./cprog" into your makefile or a script if you're especially lazy.
I would certainly agree with that if you are root, or commonly run as root, because someone may insert a local file called "ls" or some such that does something other than what the standard ls command does (such as insert the username "newuser" as a "root" user in the passwd table).
Originally Posted by citizen
If you are a "regular" user, there are cases where ./ is fine to have in the path - there is still some risk with it, but since regular users can't generally do too many bad things other than destroying their own files, it's not quite so bad.
I have certainly used a setup where ./ is in the path [at the back end tho', so if it hits anything else, it picks that first, not like Windows which applies ./ as the FIRST search path without any option to change it].
thanks, it works...i just assumed when running a program it begins a search within the current directory you're working from. Easy fix, i was getting worried for a bit.
I should, perhaps explain a bit further about my comments to citizen: It is not a good idea to "just add the current path to $PATH just like that". You should understand what that means, and consider the consequences.
In the last couple of years of working on Xen, I have almost consistently been running as root for practical reasons [ok to some extent "laziness"], and I'm so in the habit to type ./ in front of things that I've just built, that I often do that even on my Windows system. Of course it immediately spits back at me because the slash is the wrong way around :-(