programing in C++ using Ubuntu

[Guest Neezer]

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

[zkissane]

./a.out

 

 

Alternatively, you can add . to your path environment variable. Blah blah blah minor security risk, blah blah.

[Guest Neezer]

./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?

[Guest Kobalt]

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)

[zkissane]

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.

[Guest nibs]

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.