Gcc

[miscow]

Hi, noobie here.

I'm trying to gcc a helloworld in RedHat Linux 6.1, so I

gcc helloworld.c

which comiles successfully, and I end up with a.out.

But I can't get it to run, despite entering

a.out <Enter>

Can anyone help me out here? I'm following a book 'Teach Yourself Linux' by Steve Oualline and Eric Foster Johnson. The book's examples don't look like what comes up on screen.

sincerely,
cow.

[MrLinus]

Hey there,

Give a try to ./a.out .. You're path is what is determining whether it finds it locally or not. You can find out what your path is by entering echo $PATH.

Hope this helps.

[miscow]

That did the trick, thanks.

So, this is what I understand, when I type the ./ it points to my local directory, but when I don't it points to the /bin. Is this right?

Is there away for it to point directly to the right folders... where do I edit to do that?

sincerely,
cow.

[Moopsy]

You might also want to try using the -o option on GCC to give your ouput file a more logical name.
e.g.
gcc -o helloworld helloworld.c

Then you can execute it with ./helloworld

(I suppose it doesn't matter for now if you're just starting out, but having all your executable's called a.out will get annoying quite quickly I'd imagine)

[Mr. Dude]

try "gcc -o hello hello.c"
with the parameter -o you can specify the file name of the compiled file

[MrLinus]

Edit you .bash_profile file using whatever tool you are comfortable with. I personally use vi. You can find it by type
ls -l .bash_profile in your home directory.

At the end of the PATH statement.

Here's the one I created for my root user on my machine:

# User specific environment and startup programs

PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH:$HOME/bin:/usr/local/mysql/bin:.
BASH_ENV=$HOME/.bashrc
USERNAME="root"

export USERNAME BASH_ENV PATH

ALWAYS have current working directory (identified by the single . ) at the end of the PATH statement. That will mean that no matter where you are it will attempt there last. Additionally, each path location is deliniated by the colon : .

Hope this helps

[draziw]

Look at your $PATH variable... it will tell it where it's searching. In Bourne Shell, just type "set" - in csh, try using "setenv." Between those two commands (and csh uses both for different items), you should be able to find it... the shell will search the path in the order listed, stopping when it finds a match or a hit on the hash (not to confuse you or anything, but it doesn't actually search the drive each and every time, but keeps a hash in memory).

[draziw]

Originally posted here by MsMittens
ALWAYS have current working directory (identified by the single . ) at the end of the PATH statement. That will mean that no matter where you are it will attempt there last.

...though, with the added caveat, adding "current directory" to your search path is considered by some to be a fairly significant security risk.

[ph1y]

BTW, if there are programs that you're going to use really frequently, just put them in the /usr/bin directory, and then you can execute them like any other program (ls,cat,less,more,etc). Have fun!

-phly

[Vorlin]

Putting . in your PATH, anywhere, is a significant security risk albeit it's a lot less of one at the very end. What I would do is this:

1: make a script (we'll use foo for example) that looks like this:

#!/bin/sh

if [ "x"$1 = "x" ]; then
  echo "Argument: $0 directory_to_add_to_path"
elif [ ! -d $1 ]; then
  echo "Invalid directory : $1"
else
  echo "Adding to current path as \$PATH:$1"
  PATH=$PATH:$1
fi

2: add an alias into your $HOME/.bashrc file as follows:

alias addpath='$HOME/foo' (or whatever it's called, wherever it's stored)

3: log out and log back in, or re-source your .bashrc by doing . $HOME/.bashrc and you're good to go!

Note: this is a semi-gimpy way of using current directories, but notice, the script does not EXPORT the PATH, which means all child scripts/processes kicked off by that shell will not have any added paths in their inherited PATH.