To accept input from PIPE by a program 
Author Message
 To accept input from PIPE by a program

Here is a working C program. It is run like this:

$ program inFile > outFile

Now it does not run like this

$ cat inFile | program > outFile

I know many programs in unix which can take input from a pipe (stdin??)
and the first way.

Lets call the first one program1. It reads the inFile using argv[1],
and then opens the file. I would be interested in knowing how to do
the least modification to it to run it like program2.

There also may be a better way to write it so that it works in both
ways, that might require starting from scratch. Ideas on that are
also welcome.
Thanks

Sent via Deja.com
http://www.*-*-*.com/



Sun, 15 Jun 2003 09:06:41 GMT  
 To accept input from PIPE by a program
That question is off-topic here. Pipes are not part of ANSI C.
I'm sure your question will be answered immediately if you post it at
comp.unix.programmer.

Best regards,

--
Paulo J. Matos aka PDestroy
http://www.pdestroy.net
ICQ UIN - 361853

--
We live by the rules, we die by the rules!
           - The Skulls - The Movie

Quote:

> Here is a working C program. It is run like this:

> $ program inFile > outFile

> Now it does not run like this

> $ cat inFile | program > outFile

> I know many programs in unix which can take input from a pipe (stdin??)
> and the first way.

> Lets call the first one program1. It reads the inFile using argv[1],
> and then opens the file. I would be interested in knowing how to do
> the least modification to it to run it like program2.

> There also may be a better way to write it so that it works in both
> ways, that might require starting from scratch. Ideas on that are
> also welcome.
> Thanks

> Sent via Deja.com
> http://www.deja.com/



Sun, 15 Jun 2003 10:14:14 GMT  
 To accept input from PIPE by a program


 This is a public reply to your message posted:
 From group: comp.lang.c;  on Wed, 27 Dec 2000 02:14:14 -0000
 Concerning "Re: To accept input from PIPE by a program";

~ > That question is off-topic here. Pipes are not part of ANSI C.
~ > I'm sure your question will be answered immediately if you post it at
~ > comp.unix.programmer.

  I know nothing about unix programming, but find this question very
  interesting and on topic (even if arg[] is not part of the ansi
  standard).

  I hope that someone who knows the answer will be kind enough to post
  it.

  Cordially;

~ > > Here is a working C program. It is run like this:
~ > >
~ > > $ program inFile > outFile
~ > >
~ > > Now it does not run like this
~ > >
~ > > $ cat inFile | program > outFile
~ > >
~ > > I know many programs in unix which can take input from a pipe (stdin??)
~ > > and the first way.
~ > >
~ > > Lets call the first one program1. It reads the inFile using argv[1],
~ > > and then opens the file. I would be interested in knowing how to do
~ > > the least modification to it to run it like program2.
~ > >
~ > > There also may be a better way to write it so that it works in both
~ > > ways, that might require starting from scratch. Ideas on that are
~ > > also welcome.
~ > > Thanks
~ > >
~ > >
~ > > Sent via Deja.com
~ > > http://www.deja.com/
~ >
~ >

--
 Friar Broccoli
 Robert Keith Elias (Quebec, Qc, Canada)  By: kelias (from) clic.net
 Best programmer's & all purpose text editor: http://www.semware.com

 --------- I consider ALL arguments in support of my views ---------



Sun, 15 Jun 2003 11:13:59 GMT  
 To accept input from PIPE by a program

Quote:

> Here is a working C program. It is run like this:

> $ program inFile > outFile

> Now it does not run like this

> $ cat inFile | program > outFile

> I know many programs in unix which can take input from a pipe (stdin??)
> and the first way.

> Lets call the first one program1. It reads the inFile using argv[1],
> and then opens the file. I would be interested in knowing how to do
> the least modification to it to run it like program2.

> There also may be a better way to write it so that it works in both
> ways, that might require starting from scratch. Ideas on that are
> also welcome.
> Thanks

My suggestion is not to code main algorithm in the main() function.
Make a function, say program1(filein).

Then main() can call program1() with any file pointer as you wish.

main(...)
{
    ...
    if( you_have_file_to_read(...) && open_that_file(...) )
        program1( pointer_of_that_file );
    else
        program1( stdin );
    ...

- Show quoted text -

Quote:
}

> Sent via Deja.com
> http://www.deja.com/



Sun, 15 Jun 2003 11:48:48 GMT  
 To accept input from PIPE by a program

Quote:
> Here is a working C program. It is run like this:

> $ program inFile > outFile

> Now it does not run like this

> $ cat inFile | program > outFile

> I know many programs in unix which can take input from a pipe (stdin??)
> and the first way.

> Lets call the first one program1. It reads the inFile using argv[1],
> and then opens the file. I would be interested in knowing how to do
> the least modification to it to run it like program2.

> There also may be a better way to write it so that it works in both
> ways, that might require starting from scratch. Ideas on that are
> also welcome.

On a cursory reading this question looks like it's about pipes and unix
and therefore off-topic.  It is in fact about standard I/O and
argument processing and hence relevant to c.l.c.

A short answer to the question is that if you use standard I/O
(ie. <stdio.h>) your input and output will be redirectable.  How
the shell handles it is implementation specific.

To make the second example work you need to alter `program` so that
it checks its arguments and if it has not been supplied with a filename to
open then it should read from _standard input_.

The logic is a simple conditional, in pseudocode

if (I have a file to read)
{
    open the file
    write the file to _standard output_

Quote:
}

else
{
    read from _standard input_
    write to _standard output_

Quote:
}

I will not go into the details of how to determine if you have a
file (versus a shell metacharacter) as this is entirely off-topic.

Hope this helps.

Peter



Sun, 15 Jun 2003 16:11:28 GMT  
 To accept input from PIPE by a program

Quote:

> ~ > That question is off-topic here. Pipes are not part of ANSI C.
> ~ > I'm sure your question will be answered immediately if you post it at
> ~ > comp.unix.programmer.

>   I know nothing about unix programming, but find this question very
>   interesting and on topic (even if arg[] is not part of the ansi
>   standard).

If arguments to main() were not ISO C, they _would_ be off-topic, no
matter how interesting they might be. After all, I'm very interested in
calligraphy; would you say that that made it on-topic?
However, arguments to main() _are_ ISO C, and on-topic. (Note, btw, that
you don't _have_ to call them argc and argv. It would be unwise not to,
because you will confuse your colleagues and probably yourself; but you
can define main as int main(int count_clp, char **contents_clp).)

Both unfortunately and fortunately, however, getting input through a
pipe has nothing to do with main()'s arguments.
Unfortunately, because how the OS handles pipes _is_ off-topic, and
because it means that supporting pipes is going to take a bit of extra
programming.
Fortunately, because once you know that _usually_, pipes are implemented
by blasting the output of the program before the pipe into the input of
the program after it, the way of supporting them inside your program is
both on-topic and relatively simple: you just read your input from
stdin, instead of from an opened stream whose name was specified on the
command line, and output ditto with stdout; thus, using pipes is even
simpler than using command line specified filenames.

Richard



Sun, 15 Jun 2003 21:13:57 GMT  
 To accept input from PIPE by a program

Quote:

> Here is a working C program. It is run like this:
> $ program inFile > outFile
> Now it does not run like this
> $ cat inFile | program > outFile

UUOC (Useless Use of Cat).  ITYM program < inFile > outFile :)

Quote:
> I know many programs in unix which can take input from a pipe (stdin??)
> and the first way.

yes.

Quote:
> Lets call the first one program1. It reads the inFile using argv[1],
> and then opens the file. I would be interested in knowing how to do
> the least modification to it to run it like program2.

int
main(int argc, char **argv)
{
        int must_close;
        FILE *f;

        if (argc >= 2) {
                if (! (f = fopen(argv[1], "r")))        error;
                must_close = 1;
        } else {
                f = stdin;
                must_close = 0;
        }

        do_stuff(f);

        if (must_close)
                fclose(f);

        return 0;

Quote:
}

bonus points for also reading in from stdin if the filename is '-' (or some
other sentinel value).

Quote:
> There also may be a better way to write it so that it works in both
> ways, that might require starting from scratch. Ideas on that are
> also welcome.

no problem at all.  as above, just assign stdin to f (or whatever you've
called your file pointer).

--
 /"\                                                 m i k e   b u r r e l l

  X        AGAINST HTML MAIL,



Mon, 16 Jun 2003 00:14:13 GMT  
 To accept input from PIPE by a program

Quote:

>  This is a public reply to your message posted:
>  From group: comp.lang.c;  on Wed, 27 Dec 2000 02:14:14 -0000
>  Concerning "Re: To accept input from PIPE by a program";
> ~ > That question is off-topic here. Pipes are not part of ANSI C.
> ~ > I'm sure your question will be answered immediately if you post it at
> ~ > comp.unix.programmer.
>   I know nothing about unix programming, but find this question very
>   interesting and on topic (even if arg[] is not part of the ansi
>   standard).

This is indeed OT, but most Unix utilities will work also on stdin meaning
if you do not feed them with an argument they will simply use stdin:
int main (int argc, char **argv)
{
        FILE *fp;
        if (argc == 0)
          fp = stdin;
        else
          fp = fopen (argv[1], "r");
....

Quote:
}

The program of the OP, propably does not have the default action to read
stdin when no arguments.

Quote:
>   I hope that someone who knows the answer will be kind enough to post
>   it.
>   Cordially;

am


Mon, 16 Jun 2003 01:17:07 GMT  
 To accept input from PIPE by a program

Quote:
>Is there any reason not to compare FILE* objects directly?  E.g.,

> if (f != stdin) fclose(f);

You can't compare objects like that. f and stdin are pointers or addresses.
It will only compare the address, that is rather useless.

--
-hs-    Tabs out, spaces in.
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
FAQ de FCLC : http://www.isty-info.uvsq.fr/~rumeau/fclc



Mon, 16 Jun 2003 03:18:46 GMT  
 To accept input from PIPE by a program

Quote:

>>Is there any reason not to compare FILE* objects directly?  E.g.,
>> if (f != stdin) fclose(f);

This should probably be okay -- but read on.


Quote:

>You can't compare objects like that. f and stdin are pointers or addresses.
>It will only compare the address, that is rather useless.

But remember that f was set up as:

        if (some condition)
                f = something other than stdin;
        else
                f = stdin;

Hence, comparing the two pointers for equality will "do the right thing"
as long as the pointer-value of stdin never changes.

The question then becomes: is "stdin", which the standard defines as
a pointer value of type "FILE *", fixed (unchanging; not necessarily
"const") throughout the code between "f = stdin" and "if (f != stdin)"?

Certainly if stdin is an ordinary variable, or a #define like:

        #define stdin (&__stdin)

that computes the address of an ordinary variable -- and usually it
is -- this is exceedingly likely to work.  But what if stdin invokes
some function?

        #define stdin (__stdin())

What if this function returns different pointer values at different
times?  As long as all of them work to read from the standard input,
this appears to be allowed.

In other words, it seems unlikely but not impossible to have
"stdin != stdin".
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc




Mon, 16 Jun 2003 03:47:59 GMT  
 To accept input from PIPE by a program


 This is a public reply to your message posted:
 From group: comp.lang.c;  on Wed, 27 Dec 2000 16:14:13 GMT
 Concerning "Re: To accept input from PIPE by a program";

~ > int
~ > main(int argc, char **argv)
~ > {
~ >         int must_close;
~ >         FILE *f;
~ >
~ >         if (argc >= 2) {
~ >                 if (! (f = fopen(argv[1], "r")))        error;
~ >                 must_close = 1;
~ >         } else {
~ >                 f = stdin;
~ >                 must_close = 0;
~ >         }
~ >
~ >         do_stuff(f);
~ >
~ >         if (must_close)
~ >                 fclose(f);
~ >
~ >         return 0;
~ > }

  Thanks to you and the other other contributors for your replies to
  this thread.

  I have a question (which I hope is C related) about the handling of
  stdin vs keyboard input and possible conflicts.

  From your sample I wrote the following and compiled to "TESTCODE.EXE":

Quote:
>    #include <stdio.h>

>    int main(void)
>    {
>      FILE *fp, *fStdin;
>      char ch;

>      printf("Start \n");

>      fp     = fopen("DUMMY.FIL", "w");
>      fStdin = stdin;

>      ch = fgetc(fStdin);
>      while (EOF != ch)
>        {
>               fputc(ch,fp);
>          ch = fgetc(fStdin);
>        }

>      printf("End \n");

>      fclose(fp);

>    }

  If at the DOS command prompt I write:

  dir c:\ /s | TESTCODE

     first there is a long delay, while the "dir c:\ /s" stuff is written
     to a buffer file somewhere.

     the word "Start" appears on the screen

     second there is a shorter delay while the buffer file is copied into
     my DUMMY.FIL

     the word "End" appears on the screen

  If during the first  delay I push the key 'a' ten times and then
     during the second delay I push the key 'b' ten times
  then after "End" the string "aaaaaaaaaabbbbb" appears at the prompt.
  (15 byte keyboard buffer in DOS)

  QUESTION:

  Can I count on this behavior all the time?
  That is can I be sure that there will never be any competition or
  interference between stdin and keyboard input with this type of
  redirection?

  The reason I am concerned is that it is not obvious to me that the
  code does anything to block keyboard input to stdin.

 Cordially;

--
 Friar Broccoli
 Robert Keith Elias (Quebec, Qc, Canada)  By: kelias (from) clic.net
 Best programmer's & all purpose text editor: http://www.semware.com

 --------- I consider ALL arguments in support of my views ---------



Thu, 19 Jun 2003 02:53:30 GMT  
 To accept input from PIPE by a program

Quote:
>   I have a question (which I hope is C related) about the handling of
>   stdin vs keyboard input and possible conflicts.
>   From your sample I wrote the following and compiled to "TESTCODE.EXE":
>>    #include <stdio.h>

>>    int main(void)
>>    {
>>      FILE *fp, *fStdin;
>>      char ch;

>>      printf("Start \n");

>>      fp     = fopen("DUMMY.FIL", "w");
>>      fStdin = stdin;

>>      ch = fgetc(fStdin);
>>      while (EOF != ch)
>>        {
>>               fputc(ch,fp);
>>          ch = fgetc(fStdin);
>>        }

>>      printf("End \n");

>>      fclose(fp);

>>    }
>   If at the DOS command prompt I write:
>   dir c:\ /s | TESTCODE
>      first there is a long delay, while the "dir c:\ /s" stuff is written
>      to a buffer file somewhere.
>      the word "Start" appears on the screen
>      second there is a shorter delay while the buffer file is copied into
>      my DUMMY.FIL
>      the word "End" appears on the screen
>   If during the first  delay I push the key 'a' ten times and then
>      during the second delay I push the key 'b' ten times
>   then after "End" the string "aaaaaaaaaabbbbb" appears at the prompt.
>   (15 byte keyboard buffer in DOS)
>   QUESTION:
>   Can I count on this behavior all the time?

you Probably can.  this is a property of your operating system, not the C
language, but you can usually count on the fact that when your operating
system redirects stdin, it blocks the original stdin (e.g. the keyboard)
from "polluting" the stream.

Quote:
>   That is can I be sure that there will never be any competition or
>   interference between stdin and keyboard input with this type of
>   redirection?
>   The reason I am concerned is that it is not obvious to me that the
>   code does anything to block keyboard input to stdin.

right, that's because it's the operating system that does it.  i can say
with certainty that DOS (and Windows) and Unix will act this way.  my guess
is that most (if not all) other operating systems that allow the redirection
of file streams will work this way, too.  since this is outside the scope of
the C language, you can't do much about it, so it's not worth worrying
about.

--
 /"\                                                 m i k e   b u r r e l l

  X        AGAINST HTML MAIL,



Thu, 19 Jun 2003 04:09:56 GMT  
 To accept input from PIPE by a program
it is bad practice to compare pointers, exept to NULL.
it is worse practice to calculate pointers.
it is really bad to use absolute pointers for things, as it is almost
impossible to get the same things in the same places from compile to
compile.


Fri, 20 Jun 2003 03:26:11 GMT  
 To accept input from PIPE by a program

Quote:

> it is bad practice to compare pointers, exept to NULL.

i don't see why.  paragraph 3 and 6 of section 6.5.9 of my draft standard
guarantee against false positives:
       6.5.9  Equality operators

       Syntax

       [#1]

               equality-expr:
                       relational-expr
                       equality-expr == relational-expr
                       equality-expr != relational-expr

       . . .

       [#3] . . .
                . . . For any pair of operands, exactly one of  the
       relations is true.

       . . .

       [#6] Two pointers compare equal if and only if both are null
       pointers, both are pointers to the same object (including  a
       pointer  to  an  object and a subobject at its beginning) or
       function, both are pointers to one past the last element  of
       the  same  array object, or one is a pointer to one past the
       end of one array object and the other is a  pointer  to  the
       start   of   a   different  array  object  that  happens  to
       immediately follow the first array  object  in  the  address
       space.

Quote:
> it is worse practice to calculate pointers.

you mean using pointer arithmetic?  that's extremely handy at times; i don't
see why it would be considered bad practice.

Quote:
> it is really bad to use absolute pointers for things, as it is almost
> impossible to get the same things in the same places from compile to
> compile.

not if they're absolute, it's not :).  how would you propose using stdin,
stdout, and stderr at all if you're not allowed to use absolute pointers?

--
 /"\                                                 m i k e   b u r r e l l

  X        AGAINST HTML MAIL,



Fri, 20 Jun 2003 06:12:12 GMT  
 To accept input from PIPE by a program

Quote:


> > it is bad practice to compare pointers, exept to NULL.

 ... snip ...

> > it is really bad to use absolute pointers for things, as it is almost
> > impossible to get the same things in the same places from compile to
> > compile.

> not if they're absolute, it's not :).  how would you propose using stdin,
> stdout, and stderr at all if you're not allowed to use absolute pointers?

They better not be absolute pointers, or else all sorts of
processes/programs/threads whatever are stepping all over each
other.  They are pointers to a FILE structure, i.e. FILE *, which
some sort of magic has pre-opened for you and are available for
your use.  That FILE structure is somewhere in your own address
space.  The details are between you and your standard library
writer.

--


http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Fri, 20 Jun 2003 11:19:26 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How to write a C/C++ program that can accept input from a pipe

2. Some Expert level complications, Re: To accept input from PIPE by a program

3. Please Help: Accepting Characters as Input

4. Accepting input as a password from Console in C#

5. Please Help: Accepting Characters as Input

6. RLE code needs to accept array input

7. Accepting input from cursor keys...

8. Accepting input from cursor keys...

9. Can compiler accept c-source from standard input?

10. Window Not Accepting Accelerator Input

11. Accepting input without echo...

12. Need Grid Control that accepts user inputs (like spreadsheet)

 

 
Powered by phpBB® Forum Software