parameters or stdin

[David Warner]

Greetings!

I need to write some C code that will decide between either reading from
stdin or take a file name from argv and process it.

The program needs to work like all of the typical unix utilities where
the file to process is either provided from a pipe/stream or argv.

Utilities like lp, tr, grep, etc.

So, when the command:

cat filename | grep -i > filename2

or

grep -i filename > filename2

executes, this acts like the programmtic interface i need.

I have tried everything I can think of from getc, getchar, read, gets,
etc. which all did not work. I test for EOF or NULL on the return values
and the program just hangs on a terminal read. So, the command:

cat filename | testprogram -dvalue

hangs on the reading from stdin and I never get to test for EOF.

What am i missing?

Do I need to set some type of fcntl flag and control the stdin flow
similar to a wait/nowait process?

BTW, i am compiling this on HP-UX B.11.00 Unix.

I need an answer ASAP!

Thanks in advance!

[ade ishs]

David Warner wrote:

Greetings!

I need to write some C code that will decide between either reading from
stdin or take a file name from argv and process it.

The program needs to work like all of the typical unix utilities where
the file to process is either provided from a pipe/stream or argv.

Utilities like lp, tr, grep, etc.

So, when the command:

cat filename | grep -i > filename2

or

grep -i filename > filename2

executes, this acts like the programmtic interface i need.

I have tried everything I can think of from getc, getchar, read, gets,
etc. which all did not work. I test for EOF or NULL on the return values
and the program just hangs on a terminal read. So, the command:

cat filename | testprogram -dvalue

hangs on the reading from stdin and I never get to test for EOF.

What am i missing?

Probably you can show your code to see what's missing. This one works.

$ cat simplecat.c
#include <stdio.h>
#include <stdlib.h>

#define BUF_SIZE 100

int main(int argc, char ** argv)
{ char buf[BUF_SIZE + 1];
FILE * inp;

if(argc == 2)
{ inp = fopen(argv[1], "r");
if(!inp)
{ return EXIT_FAILURE;
}
}
else
{ inp = stdin;
}
while(fgets(buf , sizeof buf, inp))
{ printf("%s", buf);
}
fclose(inp);
return EXIT_SUCCESS;
}
ishs

[Richard Tobin]

In article <da************ *************** *@corp.supernew s.com>,
David Warner <da******@westb ase.com> wrote:

I need to write some C code that will decide between either reading from
stdin or take a file name from argv and process it. I have tried everything I can think of from getc, getchar, read, gets,
etc. which all did not work. I test for EOF or NULL on the return values
and the program just hangs on a terminal read.

The usual thing to do it to see whether there's a filename argument
and read from stdin if there isn't. Trying to read is useless, since
there will always be either a file or a terminal on stdin (for typical
operating systems).

-- Richard

[#2pencil]

I did the exact same thing on HP-UX... this is how my code starts...

main(int argc, char *argv[])
{
if (argc > 1) {
if the arguments are greater than 1 (1 being the command) then process
them, else use a default. I wrote this to check the similarties
between 2 files. They are allways the same, but this way I can use it
to check whatever 2 files I wish. I can option to add file names or
use defaults.

Hope this helps,
-#2pencil-
http://www.akroncdnr.com

[Michael Wojcik]

In article <d9***********@ pc-news.cogsci.ed. ac.uk>, ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

The usual thing to do it to see whether there's a filename argument
and read from stdin if there isn't. Trying to read is useless, since
there will always be either a file or a terminal on stdin (for typical
operating systems).

Unix is atypical? A great many Unix processes are executed with
neither a file nor a terminal associated with stdin. Some have
nothing associated with stdin (for Unix implementations , this
means descriptor 0 does not refer to an open entry in the file
table); many more have other types of system objects associated
with stdin.

The language requires that (for a hosted implementation) at program
startup stdin be "predefined " and "need not be opened explicitly".
That doesn't mean that it must refer to something that can success-
fully be read. It's entirely possible that the first attempt to
read from stdin will result in EOF or an error.

None of that helps with the OP's question, of course.

--
Michael Wojcik mi************@ microfocus.com

This book uses the modern technology to explain the phenomemon in the world
of Japanese animation. If you love anime so much, you'd better read this.
After you read it, you may agree that is destroying the dream of the child.
Needs Chinese viewing system. -- The Goodboy Scientific

[Richard Tobin]

In article <da*********@ne ws4.newsguy.com >,
Michael Wojcik <mw*****@newsgu y.com> wrote:

Trying to read is useless, since
there will always be either a file or a terminal on stdin (for typical
operating systems).

Unix is atypical? A great many Unix processes are executed with
neither a file nor a terminal associated with stdin.

I was referring to programs run from the command line, which was what
the OP seemed interested in.

-- Richard

[Michael Wojcik]

In article <da**********@p c-news.cogsci.ed. ac.uk>, ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <da*********@ne ws4.newsguy.com >,
Michael Wojcik <mw*****@newsgu y.com> wrote:

Trying to read is useless, since
there will always be either a file or a terminal on stdin (for typical
operating systems).

Unix is atypical? A great many Unix processes are executed with
neither a file nor a terminal associated with stdin.

I was referring to programs run from the command line, which was what
the OP seemed interested in.

Perhaps. We all write code that makes some assumptions. I merely
wanted to point out that this one - that stdin could be read
successfully - was not always justified.

It's not true of programs started from the Unix command line, either.
In ksh:

$ cat <&-
cat: cannot stat

Does anyone do that? Yes. (After all, the operator is there for a
reason.) I recently had to use this myself, to run a program (that
I couldn't modify) in the background with no controlling terminal
association.

Many Unix programs can assume that stdin is associated with a
readable entity at program startup, because their failure mode if
it is not is acceptable. Some cannot. I've dealt with programs
that had security holes if they opened a file and it received
descriptor 0, 1, or 2, because they assumed that stdin, stdout,
and stderr were valid at program startup.

--
Michael Wojcik mi************@ microfocus.com

Thanks for your prompt reply and thanks for your invitatin to your
paradise. Based on Buddihism transmigration, I realize you, European,
might be a philanthropist in previous life! -- supplied by Stacy Vickers

[Richard Tobin]

In article <da********@new s4.newsguy.com> ,
Michael Wojcik <mw*****@newsgu y.com> wrote:

Perhaps. We all write code that makes some assumptions. I merely
wanted to point out that this one - that stdin could be read
successfully - was not always justified.

The assumption relevant to this discussion is not that stdin can be
read. On the contrary, it's that the fact that stdin *can* be read
implies nothing about whether it's the intended input for the program.
I see no harm in ignoring the corner cases of unix when explaining how
to decide where to read input from.

To reiterate the possibly lost point: decide where to read from based
on the arguments, not on the state of stdin.

-- Richard

[CBFalconer]

Richard Tobin wrote:

Michael Wojcik <mw*****@newsgu y.com> wrote:

Perhaps. We all write code that makes some assumptions. I
merely wanted to point out that this one - that stdin could be
read successfully - was not always justified.

The assumption relevant to this discussion is not that stdin can
be read. On the contrary, it's that the fact that stdin *can* be
read implies nothing about whether it's the intended input for the
program. I see no harm in ignoring the corner cases of unix when
explaining how to decide where to read input from.

To reiterate the possibly lost point: decide where to read from
based on the arguments, not on the state of stdin.

On most systems it is possible to decide whether or not stdin is
connected to an interactive keyboard with slightly non-portable
code (which in turn can be replaced by something that reports
not-a-keyboard portably). This allows some easy up-front
decisions, such as whether to emit a help screen and exit. Very
useful for filters.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Joe Wright]

CBFalconer wrote:

Richard Tobin wrote:

Michael Wojcik <mw*****@newsgu y.com> wrote:

Perhaps. We all write code that makes some assumptions. I
merely wanted to point out that this one - that stdin could be
read successfully - was not always justified.

The assumption relevant to this discussion is not that stdin can
be read. On the contrary, it's that the fact that stdin *can* be
read implies nothing about whether it's the intended input for the
program. I see no harm in ignoring the corner cases of unix when
explaining how to decide where to read input from.

To reiterate the possibly lost point: decide where to read from
based on the arguments, not on the state of stdin.

On most systems it is possible to decide whether or not stdin is
connected to an interactive keyboard with slightly non-portable
code (which in turn can be replaced by something that reports
not-a-keyboard portably). This allows some easy up-front
decisions, such as whether to emit a help screen and exit. Very
useful for filters.

Pray tell. Given foo, a program which takes no arguments and expects
input from stdin, I might invoke it two ways..

foo

in which case I am expected to enter data from the keyboard or..

foo < infile

in which case data comes to stdin from a file. How can I know from
within foo, which way foo was invoked?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---