By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,193 Members | 843 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,193 IT Pros & Developers. It's quick & easy.

print out a file?

P: n/a
Just been searching google, but havent come up with anything. Just
wondering, whats the best way to print say a file.txt or other format to the
screen? A link would be great and ill read up on it. Cheers
Nov 14 '05 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Advocated <......@......com> spoke thus:
Just been searching google, but havent come up with anything. Just
wondering, whats the best way to print say a file.txt or other format to the


You could use the following C program...

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char *argv[] )
{
char buf[256];
FILE *fp;

if( argc != 2 ) {
fprintf( stderr, "Usage: %s <filename>\n", argv[0] );
return EXIT_FAILURE;
}
if( (fp=fopen(argv[1],"r")) == NULL ) {
fprintf( stderr, "Could not open file \"%s\"\n", argv[1] );
return EXIT_FAILURE;
}
while( fgets(buf,sizeof buf,fp) ) {
printf( "%s", buf );
}
printf( "\n" ); /* in case there were no newlines in the file */
fclose( fp );
return EXIT_SUCCESS;
}

(salient comments from the regulars appreciated)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #2

P: n/a

On Wed, 24 Dec 2003, Christopher Benson-Manica wrote:

Advocated <......@......com> spoke thus:

Just been searching google, but havent come up with anything. Just
wondering, whats the best way to print say a file.txt or other format
to the [screen?]
You could use the following C program...

[snip 24 lines using fgets() somewhat inappropriately]
(salient comments from the regulars appreciated)


What if you get a line in "file.txt" longer than 255 characters?
Anyway, the simple solutions are best... Use 'cat file.txt',
'type file.txt', or, if your OS doesn't have either of those,
just write your own 'cat' clone... [UNTESTED]

/* A simple 'cat' utility */

#include <stdio.h>

void process(FILE *fp)
{
if (fp == NULL) return;
while ((c=getc(fp)) != EOF)
putchar(c);
putchar('\n');
}

int main(int argc, char **argv)
{
if (argc < 2) {
process(stdin);
}
else {
int i;
for (i=1; i < argc; ++i)
process(fopen(argv[i]));
}
return 0;
}

HTH,
-Arthur
Nov 14 '05 #3

P: n/a
Arthur J. O'Dwyer wrote:

What if you get a line in "file.txt" longer than 255 characters?
Anyway, the simple solutions are best... Use 'cat file.txt',
'type file.txt', or, if your OS doesn't have either of those,
just write your own 'cat' clone... [UNTESTED]

/* A simple 'cat' utility */

#include <stdio.h>

void process(FILE *fp)
{
if (fp == NULL) return;
while ((c=getc(fp)) != EOF)
putchar(c);
putchar('\n');
}

int main(int argc, char **argv)
{
if (argc < 2) {
process(stdin);
}
else {
int i;
for (i=1; i < argc; ++i)
process(fopen(argv[i]));
}
return 0;
}


You forgot to fclose() the files. It looks like doing so will require
some changes beyond just adding the call.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Nov 14 '05 #4

P: n/a
Arthur J. O'Dwyer wrote:

[snip 24 lines using fgets() somewhat inappropriately]

What if you get a line in "file.txt" longer than 255 characters?


I don't see the problem. What do you have in mind?

--
Russell Hanneken
rg********@pobox.com
Remove the 'g' from my address to send me mail.
Nov 14 '05 #5

P: n/a
nrk
Arthur J. O'Dwyer wrote:

On Wed, 24 Dec 2003, Christopher Benson-Manica wrote:

Advocated <......@......com> spoke thus:
>
> Just been searching google, but havent come up with anything. Just
> wondering, whats the best way to print say a file.txt or other format
> to the [screen?]
You could use the following C program...

[snip 24 lines using fgets() somewhat inappropriately]

(salient comments from the regulars appreciated)


What if you get a line in "file.txt" longer than 255 characters?
Anyway, the simple solutions are best... Use 'cat file.txt',
'type file.txt', or, if your OS doesn't have either of those,
just write your own 'cat' clone... [UNTESTED]

/* A simple 'cat' utility */

#include <stdio.h>

void process(FILE *fp)
{
if (fp == NULL) return;
while ((c=getc(fp)) != EOF)
putchar(c);
putchar('\n');
}


Warning: implicit declaration of int variable :-)

-nrk.
int main(int argc, char **argv)
{
if (argc < 2) {
process(stdin);
}
else {
int i;
for (i=1; i < argc; ++i)
process(fopen(argv[i]));
}
return 0;
}

HTH,
-Arthur


Nov 14 '05 #6

P: n/a

On Wed, 24 Dec 2003, Kevin Goodsell wrote:

Arthur J. O'Dwyer wrote:

/* A simple 'cat' utility */

#include <stdio.h>

void process(FILE *fp)
{
if (fp == NULL) return;
while ((c=getc(fp)) != EOF)
putchar(c);
putchar('\n'); if (fp != stdin) fclose(fp); }

int main(int argc, char **argv)
{
if (argc < 2) {
process(stdin);
}
else {
int i;
for (i=1; i < argc; ++i)
process(fopen(argv[i]));
}
return 0;
}


You forgot to fclose() the files. It looks like doing so will require
some changes beyond just adding the call.


There. It's a hack, but I don't see anything technically wrong
with the program now. Good catch -- thanks.
BTW, is the 'if (fp != stdin)' required in the line I added? I
always have tried to avoid closing 'stdin' or 'stdout' as if they
were "regular" files, but is that something to worry about, or is it
guaranteed to work either way?

-Arthur

Nov 14 '05 #7

P: n/a

On Wed, 24 Dec 2003, Russell Hanneken wrote:

Arthur J. O'Dwyer wrote:

[snip 24 lines using fgets() somewhat inappropriately]

What if you get a line in "file.txt" longer than 255 characters?


I don't see the problem. What do you have in mind?


Three strikes in one post for me! :( You're right, in that
Chris' code does work as expected even with long lines, but
it *looks* like it shouldn't. ;) And I stand by my diagnosis
of "overly complicated," and that 'getc' is more appropriate
than 'fgets' for this application. And thus 'fgets' is
"somewhat inappropriate," right?

And as nrk points out, I was also missing the declaration of

int c;

inside function 'process'. I do that a lot in "real" code, too,
probably because the first time the variable is used is always
buried inside a bunch of parentheses.

-Arthur

Nov 14 '05 #8

P: n/a
The main idea is that the user gives a filename, i.e file.c

It will try and open this file.. if not show an error. If the file is there,
it will just print the contents of it to the screen, but the filename could
be anything at all

Nov 14 '05 #9

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]
/* A simple 'cat' utility */

#include <stdio.h>

void process(FILE *fp)
{
if (fp == NULL) return;
while ((c=getc(fp)) != EOF)
putchar(c);
putchar('\n');
}

int main(int argc, char **argv)
{
if (argc < 2) {
process(stdin);
}
else {
int i;
for (i=1; i < argc; ++i)
process(fopen(argv[i]));
}
return 0;
}


This unconditionally prints an extra '\n' after printing each file.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 14 '05 #10

P: n/a
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
What if you get a line in "file.txt" longer than 255 characters?
Um, well at least it isn't UB, right? ;)
Anyway, the simple solutions are best... Use 'cat file.txt',
'type file.txt', or, if your OS doesn't have either of those,
just write your own 'cat' clone... [UNTESTED]


Yeeeah, much better. Thanks.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #11

P: n/a
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
Chris' code does work as expected even with long lines,


Well, it "works" without UB, although I don't think one would "expect"
long lines to be truncated :) I probably should have made some note
of that behavior in my original post. I noted elsewhere that in any
case putc() is probably better regardless.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #12

P: n/a

On Fri, 26 Dec 2003, Christopher Benson-Manica wrote:

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
Chris' code does work as expected even with long lines,
Well, it "works" without UB, although I don't think one would "expect"
long lines to be truncated :) I probably should have made some note
of that behavior in my original post.


See, that's what I mean when I say it *looks* like it's wrong. :D
Take a much closer look, and you'll find that long lines are *not*
truncated -- they're just output "piecewise" in multiple calls to
fgets/fputs (or printf; I forget which you used). So the output is
absolutely correct w.r.t. long lines -- but it's weird enough code
to fool me, and then to fool you!
I noted elsewhere that in any
case putc() is probably better regardless.


Definitely. Though you'll note I didn't get my code quite right
either. ;-)

-Arthur
Nov 14 '05 #13

P: n/a
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
See, that's what I mean when I say it *looks* like it's wrong. :D
Take a much closer look, and you'll find that long lines are *not*
truncated -- they're just output "piecewise" in multiple calls to
fgets/fputs (or printf; I forget which you used). So the output is
absolutely correct w.r.t. long lines -- but it's weird enough code
to fool me, and then to fool you!


So it is, on all counts. Would have looked smarter if I'd just kept
my mouth shut ;) Goes for both of us, perhaps...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #14

P: n/a
Christopher Benson-Manica wrote:
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> spoke thus:
Chris' code does work as expected even with long lines,


Well, it "works" without UB, although I don't think one would
"expect" long lines to be truncated :) I probably should have
made some note of that behavior in my original post. I noted
elsewhere that in any case putc() is probably better regardless.


Look again. It doesn't even truncate long lines.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #15

P: n/a
On Wed, 24 Dec 2003 18:23:34 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
Advocated <......@......com> spoke thus:
Just been searching google, but havent come up with anything. Just
wondering, whats the best way to print say a file.txt or other format to the


You could use the following C program...

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char *argv[] )
{
char buf[256];
FILE *fp;

if( argc != 2 ) {
fprintf( stderr, "Usage: %s <filename>\n", argv[0] );
return EXIT_FAILURE;
}
if( (fp=fopen(argv[1],"r")) == NULL ) {
fprintf( stderr, "Could not open file \"%s\"\n", argv[1] );
return EXIT_FAILURE;
}
while( fgets(buf,sizeof buf,fp) ) {
printf( "%s", buf );
}
printf( "\n" ); /* in case there were no newlines in the file */
fclose( fp );
return EXIT_SUCCESS;
}

(salient comments from the regulars appreciated)


Where we have to use "clearerr()"?

#include <stdio.h>
#include <stdlib.h>
#if !defined(BUFSIZ)
#define BUFSIZ 256
#endif
/* here sizeof(buf)== BUFSIZ */
size_t rread(FILE* fp, char* buf, size_t* err)
{static size_t contar=0, re=0;
size_t con;

contar += (con=fread(buf, 1, BUFSIZ, fp));
if(ferror(fp))
{if(!re) {*err=contar; re=1;}
clearerr(fp);
}
return con;
}
/* here sizeof(buf)== BUFSIZ */
size_t wwrite(FILE* fp, char* buf, size_t* err, size_t num)
{static size_t contaw=0, wr=0;
size_t con;

contaw += (con=fwrite(buf, 1, num, fp));
fflush(fp);
if(!wr && con!=num)
{*err=contaw; wr=1;}
return con;
}
int read_write(FILE* fin, FILE* fout) /* fin and fout must be
opened first */
{char buf[BUFSIZ];
size_t yr=0, yw=0, num;
int c;

if(fin==stdout || fout==stdin || fin==0 || fout==0)
return -1;
if(ferror(fin))
clearerr(fin);
if(ferror(fout))
clearerr(fout);
if(feof(fin))
return 1; /* no errors */
do{num=rread(fin, buf, &yr);
if(num)
{wwrite(fout, buf, &yw, num); c=buf[--num]; }
}while(!feof(fin));
if(fout==stdout && c!='\n') c=fputc('\n', fout);
fflush(fout);
if(yr) fprintf( stderr, "Error in reading from %lu char\n",
(unsigned long) yr);
if(yw) fprintf( stderr, "Error in writing from %lu char\n",
(unsigned long) yw);
if(c==-1) fprintf( stderr, "Error in writing the last \\n ");
return c==-1 ? 0 : !(yr+yw) ;
}

void ricor(int c, char** a)
{FILE *fp;
if(a==0 || c<=0 || a[c]==0) return;
if( (fp=fopen(a[c],"r")) == NULL )
{fprintf( stderr, "I could not open file \"%s\"\n", a[c] );
ricor(++c, a);
return;
}
fprintf( stderr, "I writing the file \"%s\": \n", a[c] );
read_write(fp, stdout);
fclose(fp);
ricor(++c, a);
}
int main( int argc, char *argv[] )
{if( argc < 2 )
{fprintf(
stderr, "Usage: %s <filename_0> <filename_1> ... <filename_n>\n",
argv[0]!=NULL ? argv[0]: "This program "
);
return EXIT_FAILURE;
}

ricor(1, argv);
return EXIT_SUCCESS;
}

Nov 14 '05 #16

P: n/a
On Sat, 27 Dec 2003 12:06:19 GMT, no_name <no*@esist.eeee> wrote:
Where we have to use "clearerr()"? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_________________________#include <stdio.h>
#include <stdlib.h>
#if !defined(BUFSIZ)
#define BUFSIZ 256
#endif
/* here sizeof(buf)== BUFSIZ */
size_t rread(FILE* fp, char* buf, size_t* err)
{static size_t contar=0, re=0;
size_t con;

contar += (con=fread(buf, 1, BUFSIZ, fp));
if(ferror(fp))
{if(!re) {*err=contar; re=1;} if(!re) {*err=contar-con; re=1;}
clearerr(fp);
}
return con;
}
/* here sizeof(buf)== BUFSIZ */
size_t wwrite(FILE* fp, char* buf, size_t* err, size_t num)
{static size_t contaw=0, wr=0;
size_t con;

contaw += (con=fwrite(buf, 1, num, fp));
fflush(fp);
if(!wr && con!=num)
{*err=contaw; wr=1;} {*err=contaw-con; wr=1;}
return con;
}


Nov 14 '05 #17

P: n/a
Christopher Benson-Manica wrote:
if( argc != 2 ) {
fprintf( stderr, "Usage: %s <filename>\n", argv[0] );
If argc is 0 then argv[0] is a null pointer.
(salient comments from the regulars appreciated)


Do you mean "sapient"?

Jeremy.
Nov 14 '05 #18

P: n/a
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> spoke thus:
If argc is 0 then argv[0] is a null pointer.


On common implementations (Unix, for example), this is never the case,
correct? Good call though.
(salient comments from the regulars appreciated)

Do you mean "sapient"?


A quick check of dictionary.com confirms that my vocabulary needs
work. I'm embarassed to say I've been misusing "salient" thus for
many years. ;(

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #19

P: n/a
begin followup to Christopher Benson-Manica:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> spoke thus:
If argc is 0 then argv[0] is a null pointer.


On common implementations (Unix, for example), this is never
the case, correct? Good call though.


It is very easy to set up.
Though only few programs can actually handle this.

#include <unistd.h>
int main(int argc, char** argv, char** env)
{
char* const arg[] = { 0 };
execve("/bin/sh", arg, env);
}

--
Für Google, Tux und GPL!
Nov 14 '05 #20

P: n/a
Christopher Benson-Manica wrote:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> spoke thus:
.... snip ...
(salient comments from the regulars appreciated)


Do you mean "sapient"?


A quick check of dictionary.com confirms that my vocabulary
needs work. I'm embarassed to say I've been misusing "salient"
thus for many years. ;(


Relax. I find (Websters Encyclopedic Unabridged):

salient 1. prominent or conspicuous: /salient traits/
....
SYN: 1. important, striking, remarkable.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #21

P: n/a
CBFalconer <cb********@yahoo.com> spoke thus:
Relax. I find (Websters Encyclopedic Unabridged): salient 1. prominent or conspicuous: /salient traits/
...
SYN: 1. important, striking, remarkable.


Yeah, it kind of fits, but I always thought it meant something closer
to "germane." Maybe "germane" wasn't the connotation I wanted anyway
;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.