Compiling C++ programs

rchillal · 02-07-2005, 03:48 AM

I compiled my first C++ program on Linux
> g++ -c HelloWorld.cpp -o Hello

Now when I try to run the executable "Hello"
>./Hello
I get
> permission denied

where as if
>g++ -c HelloWorld.cpp
>g++ -o HelloWorld.o Hello
>./Hello

It runs quite properly ! Is there something wrong in compiling ? How do I compile & create an executable in a single command ?

Also how do I directly run my executables (C & C++) without having to always prefix it with "./" ?

enemorales · 02-07-2005, 04:31 AM

Hi,

I do not know about the problem with the permissions, but if you want to run programs in the current directory you have to modify your PATH variable and add ":." at the end. If you use bash as shell, then modify your .bashrc. Notice however that you do not want to do this for the root user, as it could be a security threat.

Good luck...

png · 02-07-2005, 04:57 AM

You can compile and link a program using the syntax you mention:

g++ -o program program.cpp

You won't need to issue the "g++ -c ..." command first as it is all done in the command above.

harken · 02-07-2005, 05:03 AM

Quote:

g++ -o program program.cpp

I think it's

Code:

g++ -o program.cpp program

As for what enemorales said, if you're in the same directory as the executable you don't need to add it to your path. Just issue './programname'.
Security threat?

rchillal · 02-07-2005, 05:09 AM

Thanks, I will try that out.

But still, nobody has answered to my question

"how do I directly run my executables (C & C++) without having to always prefix it with "./" ?"

Because, when I had installed RED HAT 6 (now I have Mandrake 10.1), I never had to use this prefix to run my executables.

JunctaJuvant · 02-07-2005, 05:48 AM

The following entry adds the current directory to the $PATH variable of a normal user in Slackware Linux (in my case it is in /etc/profile, maybe it is the same for you).

Code:

# For non-root users, add the current directory to the search path:
if [ ! "`id -u`" = "0" ]; then
 PATH="$PATH:."
fi

Hope that helps.

png · 02-07-2005, 05:56 AM

Ok, I know it's annoying but it's a basic security measure. By having you type "./" in front of any program in the current dir, you can be sure no one can trick you into running a fake system command (eg, a modified 'ls' executable in your $HOME). That's why "." is not in the PATH by default.

png · 02-07-2005, 05:58 AM

And no, the -o option tells g++ the desired name for the output file. If you omit it, g++ will name your executable "a.out".

JunctaJuvant · 02-07-2005, 07:10 AM

Doesn't the order in which the path is searched prevent the malicious "ls" from being executed, since the real "ls" command is found first? Just wondering.
Also, I have tested on my system with two instances of the same c program, called "ls" and "ls.bin" respectively (both only printing "hi" and then quiting). Typing "ls.bin" ran the program fine, but with "ls" it only worked by typing "./ls"
So it appears that on my system I can only run programs in this way that have an extension (like .exe, or .bin, or .abighairylamawithpurpledots), maybe it is the same with other systems.

michaelk · 02-07-2005, 09:33 AM

Extensions do not mean anything in linux. All that is required is the executable permission be set. So ls.bin is not the same thing as ls.

png · 02-07-2005, 09:43 AM

Yes, I have just tested and it happens right like that. The weird thing is, if I run 'which ls', I get the expected answer: my version of 'ls' is the one to be executed.

I have made a quick search on bash builtin commands but 'ls' is not among them.

This is quite a mystery.

JunctaJuvant · 02-07-2005, 10:03 AM

That is what I thought too, which is why I literally tried the silly extension and it worked!
If I rename both files to "test.bladiebla" and "test", then "test.bladiebla" executes without "./"
However, "test" still requires the "./" even though the permissions on both programs are the same. And yet I do not get a "no such file or directory" error, simply a newline as if I just pressed enter on a blank line.
As root user it is indeed not possible for me to run "test.bin" without "./", which is what I expected. And it does give the bash error message.
Does anyone know why this is?

JunctaJuvant · 02-07-2005, 12:45 PM

ok I'm an idiot. See "man test", lol

png · 02-08-2005, 05:27 AM

Well... I have to thank a freebsd-using friend to point me in the right direction.

The thing is, bash keeps a table with all the results it gets from PATH searches. So, when it has found a program somewhere in the PATH, it never searches for it again because its location is unlikely to change.

That is why yesterday, when I made my own 'ls', I kept running /bin/ls instead of /home/png/bin/ls.

There is a bash builtin command, hash , that shows the current contents of the search table. If you do the same test as I did, and then run 'hash', you can see exactly which version of 'ls' will be executed. Furthermore, if you erase that executable, bash will no longer be able to find it and will complain about it, even when there is another executable with the same name in the path!!!

How to fix that?

When an executable changes its location, you need to tell bash "forget what you assumed about this program" so that it will search again next time. In bash, this is done with the following command:

hash -r

This erases the full hash table.

You can see more about this in bash(1), in the "BASH BUILTIN COMMANDS" section.

BTW, in freebsd there is also the 'rehash' command that makes the shell rebuild the table.