How to run a C program's a.out in Bash Shell??

[checkers]

Ok, first things first!

I'm a 3 hour Linux newbie...I just installed Suse 8.0 this morning.

Then I installed the GNU C Compiler and all associated libs.

So, I compile good old "helloworld.c" with no worries...

cj@linux> gcc -o hello helloworld.c

Then I go to run the executable by just typing its name, hello.

I get the following:

bash: hello command not found

When I run this same code fragment on a Solaris 8.0 at school, it compiles/runs fine?

What am I missing here in Linux or maybe in this BASH Shell?

Many thanks

Checkers

[ggforrest]

I assume you are in the right directory :)

Some shells are strange that way. Try typing "./a.out" (without quotes of course).

[checkers]

Thank You very much! It works fine now with that command...never had to use it on Solaris. I guess I'll have a lot of learning to do with compilations of C programs in Linux, especially systems calls which I'm guessing will be different to those on Solaris...Thanks again...C

[chalk]

This is one of the most confusing things to people who are new to Linux. When you type the name of a binary to execute, it searches your path for that name. If it's not found in the path, it will say command not found. This is because the current directory is not part of your path.

To find out your current path type 'echo $PATH'. By putting a ./ in front of the binary name you are specifying to run the binary from the current directory. This applies, of course, to all binaries, not just c programs.

When I first started using Linux this REALLY confused me. I'd be thinking 'What do you mean, not found. It's right there!!!'

Anyway, hope this helps.

[furrycat]

It's tempting to have your .bash_profile add . to your PATH.

Don't do it!

Someone will just come along and write a script called "ls" which calls "rm -rf /" and when you change into the directory it's in and try to list the files...

[ScRapZ_1]

Originally posted by furrycat
Someone will just come along and write a script called "ls" which calls "rm -rf /" and when you change into the directory it's in and try to list the files...

Firstly, thats not going to do much unless you're root.
Secondly, why is someone else getting access to your computer/account?
...and if the both the above apply then you cant be too interested in security...

Slackware adds "." to PATH, whereas Gentoo doesnt. I'm sure theres other distros that does this aswell... just personal preference I guess

TTFN,
Scrapz :p

[mingshun]

Originally posted by checkers
Thank You very much! It works fine now with that command...never had to use it on Solaris. I guess I'll have a lot of learning to do with compilations of C programs in Linux, especially systems calls which I'm guessing will be different to those on Solaris...Thanks again...C

Yes, they are different. Distribution with different version numbers
would also have different system calls. You may like to include
your current path in your .bash_profile. Add in
"export PATH=$PATH:./", save and run it by ". ~/.bash_profile".
Try "a.out" now and see if it works.

[X_console]

Originally posted by furrycat
It's tempting to have your .bash_profile add . to your PATH.

Don't do it!

Someone will just come along and write a script called "ls" which calls "rm -rf /" and when you change into the directory it's in and try to list the files...

Actually as a regular user it's safe to add ".", but as the last element in your PATH variable. When you run a command, the shell always searches it's PATH from left to right. So if /bin comes before . then it will run /bin/ls. The danger comes with the user modifies his/her PATH to add additional programs. Say he/she adds /usr/local/share/licq/bin/licq to her PATH by doing: PATH=$PATH:/usr/local/share/licq/bin/licq

Well what that does is modifies the PATH to show /bin:/usr/bin:.:/usr/local/share/licq/bin/licq So now if someone comes along and creates a script ./licq in the user's home directory then that script will run instead of the real licq.