For example, I saved the following text as "ch03.c"
#include <stdio.h>
main ()
{
printf ("Programming is fun.\n");
}
I compiled it by typing "cc ch03.c". I then get a file called "a.out."
But when I type a.out, I get "a.out: Command not found" Any ideas?
--
Thanks,
Joe
Try typing "./a.out" instead of "a.out". The problem is that ".",
representing the current working directory, is not on the default search
path on the Mac.
If you want "." to be in your standard search path, you can add a
statement like the following to your .cshrc file (or create one if you
don't have it):
set path = ( $path . )
The next time you open a Terminal window, your path problem will be
fixed. Many will tell you, however, that putting "." in your path is a
bad idea for security reasons.
--
Dave Seaman dse...@purdue.edu
Amnesty International says Mumia Abu-Jamal decision falls short of justice.
<http://www.amnestyusa.org/news/2001/usa12192001.html>
In article <aegd2b$8...@seaman.cc.purdue.edu>, Dave Seaman
<dse...@seaman.cc.purdue.edu> wrote:
> In article <150620021657347474%joe_...@kctc.com>,
> Joe Gage Jr. <joe_...@kctc.com> wrote:
> >I was wondering if anybody could give me some advice. I am using the C
> >shell in UNIX to type in some sample C programs for a class I am
> >taking. I can't seem to call the compiled results from the command
> >line-they don't run as expected when I type in their names.
>
> >For example, I saved the following text as "ch03.c"
>
> >#include <stdio.h>
> >main ()
> >{
> > printf ("Programming is fun.\n");
> >}
>
> >I compiled it by typing "cc ch03.c". I then get a file called "a.out."
> >But when I type a.out, I get "a.out: Command not found" Any ideas?
>
> Try typing "./a.out" instead of "a.out". The problem is that ".",
> representing the current working directory, is not on the default search
> path on the Mac.
>
> If you want "." to be in your standard search path, you can add a
> statement like the following to your .cshrc file (or create one if you
> don't have it):
>
> set path = ( $path . )
>
> The next time you open a Terminal window, your path problem will be
> fixed. Many will tell you, however, that putting "." in your path is a
> bad idea for security reasons.
--
Thanks,
Joe
Or on any other Unix system, and for good reason.
> If you want "." to be in your standard search path, you can add a
> statement like the following to your .cshrc file (or create one if you
> don't have it):
>
> set path = ( $path . )
>
> The next time you open a Terminal window, your path problem will be
> fixed. Many will tell you, however, that putting "." in your path is a
> bad idea for security reasons.
Yes. And the reason is this: if you happen to be root (not
unheard of with your own box), and you get rooted, someone might
install a trojan version of a regular system command. You might be in
the directory in which this trojan lives, run "ps" or "ls", and
execute the trojan.
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
beh...@bogus.zbzoom.net
I was raised by a pack of wild corn dogs.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
> > The next time you open a Terminal window, your path problem will be
> > fixed. Many will tell you, however, that putting "." in your path is a
> > bad idea for security reasons.
>
> Yes. And the reason is this: if you happen to be root (not
> unheard of with your own box), and you get rooted, someone might
> install a trojan version of a regular system command. You might be in
> the directory in which this trojan lives, run "ps" or "ls", and
> execute the trojan.
No, if you get "rooted" then the intruder will put the trojan program in
the standard place (/bin or /usr/bin etc) and everyone will run it
automatically regardless of having . in their PATH or not.
The danger of having . in your PATH is of authorised users putting a
trojan in their home directory and tricking you into running it. This
is bad for you whether you're root or not (you could lose all *your*
files), but worse if you're root.
-- Bruce
Type:
./a.out
You may or may not have "." (current dir) in your path. But in any case,
the c-shell creates a hash table of all executables and wont find your file
the first time you try it, because it didnt exist when you logged in.
In c-shell, type
rehash
and then you should be able to run:
a.out
regards
> Type:
>
> ./a.out
>
> You may or may not have "." (current dir) in your path. But in any case,
> the c-shell creates a hash table of all executables and wont find your file
> the first time you try it, because it didnt exist when you logged in.
>
> In c-shell, type
>
> rehash
>
> and then you should be able to run:
>
> a.out
I've never needed to run rehash after compiling a program to get the
form without ./ to work, assuming . was in my path. And of course, . is
not in the path by default under X, so the raw a.out form will probably
not work, rehash or no.
>> I compiled it by typing "cc ch03.c". I then get a file called "a.out."
>> But when I type a.out, I get "a.out: Command not found" Any ideas?
>Type:
> ./a.out
>You may or may not have "." (current dir) in your path. But in any case,
>the c-shell creates a hash table of all executables and wont find your file
>the first time you try it, because it didnt exist when you logged in.
Rehashing is not necessary for the current directory, provided "." is in
your path. Since the message was "a.out: Command not found", we can
conclude that "." is not in the path (which is the default).
>In c-shell, type
> rehash
>and then you should be able to run:
> a.out
Rehashing applies only to directories that are in the search path. It
won't help if a.out is not in one of those directories. You need
"./a.out" instead.
<snip>
>
> Rehashing applies only to directories that are in the search path. It
> won't help if a.out is not in one of those directories. You need
> "./a.out" instead.
>
Using './' before your program name is not a bad habit to
establish. I've had the experience of specifying the name of
the program, e.g.,
cc myProg.c -o myProg
only to learn (after much wasted time) that I had chosen a name
of an existing program in a directory in my search path before
searching '.'.
Bob