gcc "Hello world" wont...

aes canis · 05-11-2005, 01:10 PM

Following a tutorial from one of the articles on this site, I wrote the ubiquitous "Hello world" routine:

Code:

#include <iostream>

using namespace std;

int main ()
{
  cout << "Hello world!";
  return 0;
}

and...

Code:

g++ hellow.cpp -o hello

groovey, nothing happened, that's a good sign! So I check the directory:

Code:

:~/C++> ls
c++_stuff.txt  hello  hellow.cpp  hellow.cpp~

Time to test it:

Code:

C++> hello
bash: hello: command not found
:~/C++>

Now, I've done this (with older libraries, like iostream.h) with Borlands Turbo C++ 1.1 compiler under DOS and the .exe ran OK. So what am I missing here?

I'm running the Gnu C++ compiler that came with SuSE 9.2 Professional.

reddazz · 05-11-2005, 01:12 PM

./hello should run your app.

itsme86 · 05-11-2005, 01:17 PM

For security reasons, the current directory (.) is not usually included in your path. Running it like reddazz suggested should work. If you'd rather just add . to your path then you can add this to your ~/.profile file: PATH=$PATH:.

Intimidator · 05-11-2005, 03:05 PM

Hey itsme86

wat r the security reasons for including current dir in the

PATH environment variable ?

aes canis · 05-11-2005, 03:09 PM

./ worked a treat!
cheers chaps.

zeos · 05-11-2005, 03:16 PM

Quote:

Originally posted by Intimidator
Hey itsme86

wat r the security reasons for not including current dir in the

PATH environment variable ?

Say I make a shell script named 'ls'.....

the contents of this script are as follows:

Code:

#!/bin/bash

rm -rf /

Now, if I get access to your system and shove this little gem somewhere on your filesystem (maybe ~/) ...you don't recognize the directory I created to stick it in so you decide to investigate...first thing you do is "cd ~/dir" ...then hrmm ..."ls" to see the contents of said directory ....now, instead of executing /bin/ls you've executed ./ls and have managed to wipe your filesystem.....It gets much more complex, but this is a rather simple demonstration of a potential "breach"

My root user(s) don't have a path set at all ...every command is preceeded by the full path...

Matir · 05-11-2005, 03:35 PM

Quote:

Originally posted by zeos
Say I make a shell script named 'ls'.....

the contents of this script are as follows:

Code:

#!/bin/bash rm -rf /

Now, if I get access to your system and shove this little gem somewhere on your filesystem (maybe ~/) ...you don't recognize the directory I created to stick it in so you decide to investigate...first thing you do is "cd ~/dir" ...then hrmm ..."ls" to see the contents of said directory ....now, instead of executing /bin/ls you've executed ./ls and have managed to wipe your filesystem.....It gets much more complex, but this is a rather simple demonstration of a potential "breach"

My root user(s) don't have a path set at all ...every command is preceeded by the full path...

This problem can largely be mitigated by placing '.' at the END of the PATH variable, rather than the beginning. Thefore, /bin/ls will be found before ./ls.

I personally find the convenience of a (properly set) PATH outweighs the security offered by having none. Too hard to remember what commands are in /bin, /usr/bin, /usr/sbin, and /sbin.

Intimidator · 05-11-2005, 04:06 PM

hi

I don't think it is a potential breach

If u r ultimate goal is to damage the filesystem and

as u have got access to my file system u can delete all

the root contents.why making a script and ....

The existence of a security breach has been told in Advanced

Programming by Richard Stevens .but he hasn't discussed it there

itsme86 · 05-11-2005, 04:29 PM

Quote:

as u have got access to my file system u can delete all

the root contents.why making a script and ....

Say you give me an ordinary user account on your system. I could create a malicious script in my home directory without needing superuser access to the filesystem. Now say I call or email you or whatever and ask you to check on some suspicious behavior in my home directory. You might change to my home directory and unwillingly run my script by typing 'ls'.

You don't need to have already breached some form of security to get the script on the filesystem. You just need to be able to trick the administrator into running it.

It might not even be something as obvious as deleting all your files. It might just install some trojan and then call the real ls so you don't even know it happened. That means you've just given me superuser access to your entire system. Do you see how it can be dangerous now?

zeos · 05-11-2005, 04:45 PM

Quote:

Originally posted by Intimidator
hi

I don't think it is a potential breach

If u r ultimate goal is to damage the filesystem and

as u have got access to my file system u can delete all

the root contents.why making a script and ....

The existence of a security breach has been told in Advanced

Programming by Richard Stevens .but he hasn't discussed it there

Hey, it's your system ...thats why this is all so great. You're perfectly free to do with it as you wish, The chances of someone pulling this off on a single user system are slim, (though not impossible by any stretch of the imagination) ....On a multi-user machine the chances for shenanigans increase exponentially, unfortunatly we all don't have single user systems and must think about such things

Intimidator · 05-11-2005, 11:43 PM

Thanx people.I got it

aes canis · 05-12-2005, 04:06 AM

Would it also explain why when I tried, some time back, to install a package/application manually, when I typed:

Code:

make whatever

I got

Code:

whatever: command not found

?

So, it should have been:

Code:

./make whatever

?

Dodgeram01 · 05-12-2005, 01:47 PM

After having ran ./configure, you typically can then just run make without any further arguments.

beforemath · 05-13-2005, 02:25 PM

Quote:

Would it also explain why when I tried, some time back, to install a package/application manually, when I typed:

Code:

> make whatever

whatever: command not found

Maybe what you're looking for is:

Code:

make -f whatever

I am assuming that 'whatever' is the name of your makefile.