Guest Neezer Posted July 11, 2006 Posted July 11, 2006 I am having trouble running a program that I have compiled with the gcc. I have compiled the program, and the a.out file shows when i type the ls command. when i type a.out to try to run the program in the terminal, it says "bash: a.out: c;ommand not found" any suggestions? thanks Share this post Link to post Share on other sites More sharing options...
zkissane Posted July 11, 2006 Posted July 11, 2006 ./a.out Alternatively, you can add . to your path environment variable. Blah blah blah minor security risk, blah blah. Share this post Link to post Share on other sites More sharing options...
Guest Neezer Posted July 11, 2006 Posted July 11, 2006 ./a.out Alternatively, you can add . to your path environment variable. Blah blah blah minor security risk, blah blah. The ./a.out worked fine. what do you mean by at . to my path environment variable? Share this post Link to post Share on other sites More sharing options...
Guest Kobalt Posted July 11, 2006 Posted July 11, 2006 He means ADD "." to the path environment variable. So you don't have to do ./blah or ./foo (though you still could if you want) Share this post Link to post Share on other sites More sharing options...
zkissane Posted July 11, 2006 Posted July 11, 2006 When you type in a command in Linux, it searches the locations listed in the "path" environment variable (think of it kind of like a registry setting, it's just out there and you don't really see it unless you look for it). Usual locations are /bin, /sbin (depending on the paranoia level of the distribution/sysadmin), /usr/bin, /usr/local/bin, /usr/sbin, and /usr/local/sbin. The shell searches these locations for a program that matches the command that you typed in and runs it, if it exists, or says "command not found" if it doesn't exist. If you type in a qualified path, though, such as /home/user/a.out, or even ./a.out, the interpreter starts the search there. That's why ./a.out works, but a.out doesn't. The reason the current working directory is usually omitted from the path variable goes something like this: Suppose you inadvertantly download some malware that's in a zip file. The zip contains 2 files. One is a normal type program (the thing you want), and another is a shell script that looks like this: rm -rf /home/`whoami` This would wipe out your entire home directory if you ran it. But instead of being called run_me_and_i_will_wipe_out_your_home_directory.sh, suppose it's called ls instead. Suppose your path environment variable includes the current working directory. Suppose you cd into the directory with this file in it, and type ls, expecting a directory listing. Bang, you're dead. You've just run the bad version of ls that's in your current directory, instead of the proper one that's in /bin. Most of the time, the increased risk of adding . to your path is fairly low. The default behavior can be pretty annoying, especially for programmers. To add it, you need to edit one of your login shell's config files. .bash_profile is the right one for bash; I don't know what the proper files are for the other shells. Share this post Link to post Share on other sites More sharing options...
Guest nibs Posted July 12, 2006 Posted July 12, 2006 I've always found having . not in path to useful, but then I'm one of those people exclude /sbin from path either. The small annoyance of typing an additional ./(program name) never seemed to bother me much. Share this post Link to post Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now