how to pass a file to a c program

[neha_chhatre]

How to pass a text file to a c program ???

Is it using abstract data types?? (eg. using arg v,arg
c)..........................???

 

[Malcolm McLean]

How to pass a text file to a c program ???

Is it using abstract data types?? (eg. using arg v,arg
c)..........................???

You've got two choices.

Either pass in the path to the file on the commandline and, as Army1987
said, use fp = fopen(argv[1], "r") where fp is a FILE *.

Alternatively, most plarforms allow you to pipe a file to standard input. So
you can get the file line by line by calling fgets(), or character by
character by calling getchar(). You could also call gets(), but that suffers
from the problem that long lines might crash your program.

The first method is more common.

 

[Mark McIntyre]

How to pass a text file to a c program ???

Is it using abstract data types?? (eg. using arg v,arg
c)..........................???

You've got two choices.

Either pass in the path to the file on the commandline and, as Army1987
said, use fp = fopen(argv[1], "r") where fp is a FILE *.

Alternatively, most plarforms allow you to pipe a file to standard
input. So you can get the file line by line by calling fgets(), or
character by character by calling getchar(). You could also call gets(),
but that suffers from the problem that long lines might crash your program.

The first method is more common.

Don't think thats necessarily the case - there's a HUGE number of
commandline programmes that work by piping stdin and stdout between each
other. Look at any linux/unix shell script...

ps -ef | grep foo | awk '{printf("%s %s\n",$2,$8)}' | grep bar

 

[Keith Thompson]

How to pass a text file to a c program ???

Is it using abstract data types?? (eg. using arg v,arg
c)..........................???

You've got two choices.

Either pass in the path to the file on the commandline and, as
Army1987 said, use fp = fopen(argv[1], "r") where fp is a FILE *.

Alternatively, most plarforms allow you to pipe a file to standard
input. So you can get the file line by line by calling fgets(), or
character by character by calling getchar(). You could also call
gets(), but that suffers from the problem that long lines might crash
your program.

The first method is more common.

Yes, you could call gets(), but don't.

Never ever use the gets() function. It cannot be used safely. I
don't know why Malcolm even mentioned it.

 

[Malcolm McLean]

How to pass a text file to a c program ???

Is it using abstract data types?? (eg. using arg v,arg
c)..........................???

You've got two choices.

Either pass in the path to the file on the commandline and, as
Army1987 said, use fp = fopen(argv[1], "r") where fp is a FILE *.

Alternatively, most plarforms allow you to pipe a file to standard
input. So you can get the file line by line by calling fgets(), or
character by character by calling getchar(). You could also call
gets(), but that suffers from the problem that long lines might crash
your program.

The first method is more common.

Yes, you could call gets(), but don't.

Never ever use the gets() function. It cannot be used safely. I
don't know why Malcolm even mentioned it.

Because it works on stdin. The OP will naturally wonder why getchar()
doesn't take a FILE *parameter whilst fgets() does.

 

[Richard Heathfield]

Malcolm McLean said:

Because it works on stdin.

No, it doesn't. It breaks on stdin.

The OP will naturally wonder why getchar()
doesn't take a FILE *parameter whilst fgets() does.

So tell him about getc.

 

[CBFalconer]

.... snip ...

Alternatively, most plarforms allow you to pipe a file to standard
input. So you can get the file line by line by calling fgets(), or
character by character by calling getchar(). You could also call
gets(), but that suffers from the problem that long lines might
crash your program.

If you have the slightest inclination to use gets restrain it
(dangerous) and get ggets (note the extra g, for good gets).
Written in standard C, put in public domain, and available at:

<http://cbfalconer.home.att.net/download/>

 

[CBFalconer]

.... snip ...


Because it works on stdin. The OP will naturally wonder why
getchar() doesn't take a FILE *parameter whilst fgets() does.

So does ggets. If you want a file parameter use fggets.

 

[Army1987]

Either pass in the path to the file on the commandline and, as Army1987
said, use fp = fopen(argv[1], "r") where fp is a FILE *.

Alternatively, most plarforms allow you to pipe a file to standard
input. So you can get the file line by line by calling fgets(), or
character by character by calling getchar(). You could also call gets(),
but that suffers from the problem that long lines might crash your program.

The first method is more common.

Don't think thats necessarily the case - there's a HUGE number of
commandline programmes that work by piping stdin and stdout between each
other. Look at any linux/unix shell script...

ps -ef | grep foo | awk '{printf("%s %s\n",$2,$8)}' | grep bar

You don't have to decide. Just can code in a way which works in both ways,
such as
if (argc > 2) {
in = fopen(argv[1], "r");
if (in == NULL) {
fprintf(stderr, "Cannot open '%s' for reading: %s\n",
argv[1], strerror(errno));
exit(EXIT_FAILURE);
}
} else {
in = stdin;
}

 

[Christopher Benson-Manica]

If you have the slightest inclination to use gets restrain it
(dangerous) and get ggets (note the extra g, for good gets).

It's a pity that it isn't possible to write the gggets() function (get
ggets()) in standard C

 

[William Pursell]

You don't have to decide. Just can code in a way which works in both ways,
such as
if (argc > 2) {

/* To be thorough, I would add a close here. */
if( fclose( stdin ))
/* handle_error */;

in = fopen(argv[1], "r");
if (in == NULL) {
fprintf(stderr, "Cannot open '%s' for reading: %s\n",
argv[1], strerror(errno));
exit(EXIT_FAILURE);
}
} else {
in = stdin;
}

See addendum above. No point in leaving unused resources open.

 

[Peter Nilsson]

         /* To be thorough, I would add a close here. */

It sounds more like work creation than being thorough.

         if( fclose( stdin ))
             /* handle_error */;

Handle error? If it ain't broken, don't fix it!

       in = fopen(argv[1], "r");

       }
   } else {
       in = stdin;
   }

See addendum above.  No point in leaving unused
resources open.

But why close a resource that gets closed on
program termination anyway? Why preclude the
possibility of using stdin in the cases where
a file name is supplied? Note there is no
portable way of restoring console input if you
close stdin.

 

[William Pursell]

/* To be thorough, I would add a close here. */

It sounds more like work creation than being thorough.

if( fclose( stdin ))
/* handle_error */;

Handle error? If it ain't broken, don't fix it!

in = fopen(argv[1], "r");

}
} else {
in = stdin;
}

See addendum above. No point in leaving unused
resources open.

But why close a resource that gets closed on
program termination anyway? Why preclude the
possibility of using stdin in the cases where
a file name is supplied? Note there is no
portable way of restoring console input if you
close stdin.

The main reason is to catch the coding error:

in_file = stdin;
....
fread( stdin ...) /* oops, should have read from in_file ! */

Also, there are many times when a program bumps into the
upper limit on available file descriptors. Granted, having
only 1 more will probably not avoid the problem, but
on a system which only gives you 16, one is
pretty substantial.

Clearly, a program that wants to take input from
stdin and a file shouldn't close stdin, but it
is a mistake to refer to stdin as "console
input". In the following, ain't no console
input to any of the programs:

$ < foo grep pattern | grep -v foo | sed 's/foo/bar/g' | wc -l

stdin is NOT the keyboard, and stdout is NOT the terminal.
Often, a tty is attached to the std I/O streams, but it
is a mistake to always think of them that way, and leads
to many programmers doing stupid things like corrupting the
output stream with stupid messages. Eg:
printf( "working: processed %d buffers so far\r", buf_count );
Somehow, that programmer has the notion that stdout is
a terminal rather than the standard place to write
output.

 

[Peter Nilsson]

You don't have to decide. Just can code in a way
which works in both ways, such as
   if (argc > 2) {

     /* To be thorough, I would add a close here. */

It sounds more like work creation than being thorough.

     if( fclose( stdin ))
         /* handle_error */;

Handle error? If it ain't broken, don't fix it!

       in = fopen(argv[1], "r");

       }
   } else {
       in = stdin;
   }

See addendum above.  No point in leaving unused
resources open.

But why close a resource that gets closed on
program termination anyway? Why preclude the
possibility of using stdin in the cases where
a file name is supplied? Note there is no
portable way of restoring console input if you
close stdin.

The main reason is to catch the coding error:

in_file = stdin;
...
fread( stdin ...) /* oops, should have read from
in_file ! */

Then you should state _that_ as your reason, although
I still wouldn't see it as a justification. It's
rarely useful to rely on UB informing you of your
mistakes. It certainly isn't reliable in my
experience.

Also, there are many times when a program bumps
into the upper limit on available file descriptors.

Where does the standard state closing stdin will free up
an extra 'file descriptor'.

 Granted, having only 1 more will probably not avoid
the problem, but on a system which only gives you 16,
one is pretty substantial.

You're only guaranteed a minimum of 8, but even then,
fopen can fail for any reason. I can't recall ever
needing 8 open streams (or even 5), but I guess there
are niche cases. I just don't see those niche cases
as par for the course.

 

[CBFalconer]

.... snip ...

Where does the standard state closing stdin will free up
an extra 'file descriptor'.


You're only guaranteed a minimum of 8, but even then, fopen can
fail for any reason. I can't recall ever needing 8 open streams
(or even 5), but I guess there are niche cases. I just don't see
those niche cases as par for the course.

C & V please. Where, in the C Standard, do you see any mention of
a limit on file descriptors, or even a definition of a file
descriptor. Or mention of a limit or guarantee on the count of
file streams.

 

[Ben Bacarisse]

C & V please. Where, in the C Standard, do you see any mention of
a limit on file descriptors, or even a definition of a file
descriptor. Or mention of a limit or guarantee on the count of
file streams.

7.19.3 Files, paragraph 15 (and 7.19.1 paragraph 3 for the meaning of
FOPEN_MAX).

Peter Nilsson used 'file descriptor' because the OP did. Is putting
in scare quote not enough for you?

 

[CBFalconer]

7.19.3 Files, paragraph 15 (and 7.19.1 paragraph 3 for the meaning of
FOPEN_MAX).

Peter Nilsson used 'file descriptor' because the OP did. Is putting
in scare quote not enough for you?

It's high time for a set of abject apologies from me. Thanks for
the correction.

 

[William Pursell]

Where does the standard state closing stdin will free up
an extra 'file descriptor'.

I'm sure you're aware that the standard does not talk
about file descriptors. I was referring to the non-standard
resource available on many systems, but the principal
applies to FILE *'s as well.

You're only guaranteed a minimum of 8, but even then,
fopen can fail for any reason.

Yes, and if a program happens to need 8 open files, it's silly
to let stdin stay open (if its unused) and cause fopen to
fail.

I can't recall ever
needing 8 open streams (or even 5), but I guess there
are niche cases. I just don't see those niche cases
as par for the course.

But the principal of deleting/closing/freeing unused resources
is sound.