469,903 Members | 1,806 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,903 developers. It's quick & easy.

Detecting a PIPE in a program

Stu

I have the following code in a "C" program.

test_prog.c
main()
{
while ( fgets ( buffer, sizeof(buffer), stdin) != NULL)
{
.....
.....
}
}
I want to run the program like this:

ls | test_prog

Is there anyway I can detect in my program if I am being feed
("PIPPED") data.

If I just run my program like this:

test_prog

it sits and waits. I want to put the smarts in it to see if it is
actually getting data feed to it. If not, than I can take action.

Ant sample "C" code tidbets would be appreciated.
Thanks in advance for all that answer this post!!

Nov 14 '05 #1
9 1791
In article <11**********************@g14g2000cwa.googlegroups .com>,
Stu <be********@hotmail.com> wrote:
Is there anyway I can detect in my program if I am being feed
("PIPPED") data.


I think you mean PIPED :-) And probably what you really want to know
is whether the input is a terminal; a file should most likely be
treated the same way as a pipe.

Anyway, there's no way to do this in standard C. Your operating
system may provide a way to do it. For example, in unix you can
determine whether stdin is a terminal by using isatty(0).

-- Richard
Nov 14 '05 #2
Stu wrote:

I have the following code in a "C" program.

test_prog.c
main()
{
while ( fgets ( buffer, sizeof(buffer), stdin) != NULL)
{
....
....
}
}

I want to run the program like this:

ls | test_prog

Is there anyway I can detect in my program if I am being feed
("PIPPED") data.

If I just run my program like this:

test_prog

it sits and waits. I want to put the smarts in it to see if it is
actually getting data feed to it. If not, than I can take action.


Here is a non-portable routine I use for the purpose. It gets
called with something like "if (akeyboard(stdin)) helpandquit();"
It also works with TC2.01 from the Borland museum.

/* ------------------- */

/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);
# endif
#endif
return ((fp != NULL) && isatty(fileno(fp)));
} /* akeyboard */

--
"If you want to post a followup via groups.google.com, 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
Nov 14 '05 #3
CBFalconer <cb********@yahoo.com> wrote:
/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);


Only "very likely" to be non-portable?

Richard
Nov 14 '05 #4
CBFalconer <cb********@yahoo.com> writes:
[...]
Here is a non-portable routine I use for the purpose. It gets
called with something like "if (akeyboard(stdin)) helpandquit();"
It also works with TC2.01 from the Borland museum.

/* ------------------- */

/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);
# endif
#endif
return ((fp != NULL) && isatty(fileno(fp)));
} /* akeyboard */


Why do you declare the fileno() and isatty() functions rather than
#include'ing whatever header declares them?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #5
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);


Only "very likely" to be non-portable?


Yup, in the sense that it has a finite chance of failing on your
conforming system. Would you rather I claimed it to be portable,
or didn't even mention it?

--
"If you want to post a followup via groups.google.com, 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
Nov 14 '05 #6
Keith Thompson wrote:
CBFalconer <cb********@yahoo.com> writes:
[...]
Here is a non-portable routine I use for the purpose. It gets
called with something like "if (akeyboard(stdin)) helpandquit();"
It also works with TC2.01 from the Borland museum.

/* ------------------- */

/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);
# endif
#endif
return ((fp != NULL) && isatty(fileno(fp)));
} /* akeyboard */


Why do you declare the fileno() and isatty() functions rather than
#include'ing whatever header declares them?


Because they live in headers in which they are disabled by -ansi
-pedantic. I know about this location, and I want the warnings
elsewhere in the code. I even commented that.

--
"If you want to post a followup via groups.google.com, 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
Nov 14 '05 #7

Stu wrote:
Is there anyway I can detect in my program if I am being feed
("PIPPED") data.


Maybe.. depending on platform. In the *nix world, you could
try something like this:

.. #include <stdio.h>
.. #include <unistd.h>
.. #include <sys/stat.h>

.. int main()
.. {
.. struct stat st;
..
.. if ( fstat(fileno(stdin),&st) < 0) { perror("fstat"); exit(0);
}
.. if (S_ISFIFO(st.st_mode)) { printf("Pipe\n"); }
.. else if (S_ISCHR(st.st_mode)) { printf("Character device\n");
}
.. else if (S_ISREG(st.st_mode)) { printf("Regular file\n"); }
..}

But usually this kind of detection is not among the best of ideas...
for determining input type rather than setting aside a command line
option or separate binary to give the user control of input method.

(You can't be too sure of the underlying input, actually... and by
making a decision based on input device.. you risk sacrificing
generality)

Nov 14 '05 #8
On Thu, 03 Feb 2005 01:54:13 +0000, CBFalconer wrote:
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);


Only "very likely" to be non-portable?


Yup, in the sense that it has a finite chance of failing on your
conforming system. Would you rather I claimed it to be portable,
or didn't even mention it?


I think Richard would rather you stated that it is non-portable without
qualification.

Lawrence

Nov 14 '05 #9
CBFalconer <cb********@yahoo.com> wrote:
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);


Only "very likely" to be non-portable?


Yup, in the sense that it has a finite chance of failing on your
conforming system. Would you rather I claimed it to be portable,
or didn't even mention it?


In the context of c.l.c, it not very likely, but with certainty
non-portable. In fact, IIRC the solution you give isn't even guarantee
to work correctly under exotic circumstances (over a serial line springs
to mind), but I could be wrong; that's the danger of non-portable code
in c.l.c! (Of cource, the OP isn't likely to be in such unusual
circumstances, but still...)

Richard
Nov 14 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Ruben | last post: by
2 posts views Thread by Brian | last post: by
7 posts views Thread by Greg | last post: by
1 post views Thread by David Reed | last post: by
reply views Thread by olaf.dietsche | last post: by
2 posts views Thread by Igna | last post: by
11 posts views Thread by 7stud | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.