Hello.
Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
31  4017 
Nikos Chantziaras wrote On 08/01/07 09:50,:
Hello.
Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action. They will remain so
until the program ends, or you close them, or an I/O
error occurs. I/O errors can be detected by using the
ferror() function. If you close any of these streams
you ought to know you've done it. Writing code to
determine the streams' state after the program containing
the code exits is left as an exercise for the reader ;-)
-- Er*********@sun.com
In article <1185978665.736059@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
>Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
I don't think so. On unix, a natural thing would be call fstat() and
see if you get EBADF. But it would be more portable just to not do
it: use some other criterion to decide whether to use stdin. That's
the typical unix approach: "cat" reads stdin only if it doesn't have
any filename arguments; it doesn't try to determine whether reading
stdin would block.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Nikos Chantziaras wrote:
Hello.
Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
A three standard streams, stdin, stdout, and stderr are always opened and
initialised when a Standard C program begins execution. It might then close
or reopen them. It's not possible in an arbitrary position within the
program to find out whether stdin is open or is connected to the input
device. If you close or reopen stdin, you'll have to manually keep track of
this detail yourself.
Any system specific methods to do this are topical in groups for those
systems, not here.
Richard Tobin wrote:
In article <1185978665.736059@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
Doesn't the C Standard require it to be so?
Eric Sosman wrote:
Nikos Chantziaras wrote On 08/01/07 09:50,:
>Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action. They will remain so
until the program ends, or you close them, or an I/O
error occurs. I/O errors can be detected by using the
ferror() function. If you close any of these streams
you ought to know you've done it. Writing code to
determine the streams' state after the program containing
the code exits is left as an exercise for the reader ;-)
I formulated it a bit "weird". It's porting work, btw, (from win32 to
"as portable as possible") so not everything is 100% clear to even me,
since I'm not the implementor of the original; I just do the porting ;)
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
On Wed, 01 Aug 2007 18:03:19 +0300, Nikos Chantziaras wrote:
Eric Sosman wrote:
>Nikos Chantziaras wrote On 08/01/07 09:50,:
>>Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action. They will remain so
until the program ends, or you close them, or an I/O
error occurs. I/O errors can be detected by using the
ferror() function. If you close any of these streams
you ought to know you've done it. Writing code to
determine the streams' state after the program containing
the code exits is left as an exercise for the reader ;-)
I formulated it a bit "weird". It's porting work, btw, (from win32 to
"as portable as possible") so not everything is 100% clear to even me,
since I'm not the implementor of the original; I just do the porting ;)
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
Have you tried feof(stdin) or ferror(stdin)?
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)
Nikos Chantziaras wrote:
Eric Sosman wrote:
>Nikos Chantziaras wrote On 08/01/07 09:50,:
>>Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action. They will remain so
until the program ends, or you close them, or an I/O
error occurs. I/O errors can be detected by using the
ferror() function. If you close any of these streams
you ought to know you've done it. Writing code to
determine the streams' state after the program containing
the code exits is left as an exercise for the reader ;-)
I formulated it a bit "weird". It's porting work, btw, (from win32 to
"as portable as possible") so not everything is 100% clear to even me,
since I'm not the implementor of the original; I just do the porting ;)
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
The closest you can come within Standard C is the feof function. It returns
a non-zero value if the end-of-file indicator has been set for it's
argument, which must be a FILE*. The end-of-file indicator would have been
set by the previous I/O operation on that stream, example, a getc call or
an fgets call.
The other possibility for C's I/O functions to return EOF, (which is a macro
defined in stdio.h), is for a read or write error. In this case the
function ferror will return a non-zero value on the concerned stream.
On Wed, 01 Aug 2007 14:36:22 +0000, Richard Tobin wrote:
In article <1185978665.736059@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
On a hosted implementation, they are required to be opened at
program startup, so I think that if something goes wrong, either
the program cannot be started (i.e. main() cannot be called) at
all, or there will be a valid pointer-to-FILE called stdin, but
ferror(stdin) will be nonzero and every operation on it will fail
(e.g. return EOF).
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)
Army1987 wrote:
On Wed, 01 Aug 2007 18:03:19 +0300, Nikos Chantziaras wrote:
>Eric Sosman wrote:
>>Nikos Chantziaras wrote On 08/01/07 09:50,:
Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
[...]
[...]
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
Have you tried feof(stdin) or ferror(stdin)?
Yes. But AFAIK, feof() checks the EOF indicator of a stream, and that
indicator is only set after actually trying to read from the stream.
feof(stdin) therefore would never return non-zero right at the start of
the program (when nothing has been read from stdin yet).
santosh wrote:
Nikos Chantziaras wrote:
>[...]
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
The closest you can come within Standard C is the feof function. It returns
a non-zero value if the end-of-file indicator has been set for it's
argument, which must be a FILE*. The end-of-file indicator would have been
set by the previous I/O operation on that stream, example, a getc call or
an fgets call.
The other possibility for C's I/O functions to return EOF, (which is a macro
defined in stdio.h), is for a read or write error. In this case the
function ferror will return a non-zero value on the concerned stream.
I already suspected that getting information about EOF on an I/O
operation that has yet to happen is not possible with standard C. I
guess I'll just have to use fstat() (or even select()). (Even though
the primary target for the port is Unix, I always try to find a standard
C solution first, then going down the road of standards - POSIX, BSD,
SYSV, etc, with kernel calls being the last resort).
Nikos Chantziaras wrote:
Army1987 wrote:
>On Wed, 01 Aug 2007 18:03:19 +0300, Nikos Chantziaras wrote:
>>Eric Sosman wrote:
Nikos Chantziaras wrote On 08/01/07 09:50,:
Is there a way to check if the current process has an stdin handle?
In the win32 API, one can do:
>
_eof(_fileno(stdin))
>
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
[...]
[...]
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
Have you tried feof(stdin) or ferror(stdin)?
Yes. But AFAIK, feof() checks the EOF indicator of a stream, and that
indicator is only set after actually trying to read from the stream.
feof(stdin) therefore would never return non-zero right at the start of
the program (when nothing has been read from stdin yet).
Quite rightly so. How can a program or the system predict that I'll signal
end-of-file with next key sequence without blocking for the key codes to
arrive?
Some libraries can use special system specific APIs to "peek ahead" into the
system's input buffer and look for the end-of-file sequence without
involving an actual read function, but Standard C doesn't work this way.
You'll have to look at your system's terminal facilities to find out a way
to do this.
Nikos Chantziaras wrote:
>Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
The following code does not discriminate between a stream at EOF and
other possible error conditions. (stream invalid, not-open, etc.)
#include <stdio.h>
int stream_has_some_data(FILE *stream)
{
int c = getc(stream);
if (c != EOF)
{
ungetc(c, stream); /* add check for errors */
return 1;
}
return 0;
}
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
In article <pa****************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:
>> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
>Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
>On a hosted implementation, they are required to be opened at
program startup, so I think that if something goes wrong, either
the program cannot be started (i.e. main() cannot be called) at
all, or there will be a valid pointer-to-FILE called stdin, but
ferror(stdin) will be nonzero and every operation on it will fail
(e.g. return EOF).
The latter is what happens on all the implementations I'm familiar with.
For example, on unix (using bash as a shell) then "cat <&-" will result
in the unix file descriptor 0 being not open, so that reads from stdin
return EOF with errno set to EBADF.
So yes, you're right, they are open in the strict C sense of being a
usable FILE *, but I assume the OP wanted to be sure that stdin was
"really open", in the sense of being connected to something.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Eric Sosman <Er*********@sun.comwrote:
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Is this guaranteed? I though a process can be started with any or all
of the standard streams closed.
For example, a Unix application to start an arbitrary program as a
"daemon" by, among other things, closing stdin, stdout and stderr
before calling an exec???() function.
On the other hand, I just read on the OpenGroup man page for exec that
"If file descriptors 0, 1, and 2 would otherwise be closed after a
successful call to one of the exec family of functions, ... <snip...
implementations may open an unspecified file for each of these file
descriptors in the new process image."
What does the C standard require? (I couldn't find an answer on N1124)
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
Richard Tobin wrote On 08/01/07 10:36,:
In article <1185978665.736059@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
As far as C is concerned, yes (7.19.3p7). They might
not be "really open" from the platform's point of view --
for example, an implementation might defer the "low-level
open" that underlies stderr until the program actually
writes something to it. Still, the implementation must
behave as if stderr has been open all along -- in particular,
if the "low-level open" fails, this will have to show up
as an I/O error in the output function, not as a failure in
the (non-existent) fopen call.
-- Er*********@sun.com
In article <f8**********@aioe.org>, santosh <sa*********@gmail.comwrote:
>Yes. But AFAIK, feof() checks the EOF indicator of a stream, and that
indicator is only set after actually trying to read from the stream.
feof(stdin) therefore would never return non-zero right at the start of
the program (when nothing has been read from stdin yet).
>Quite rightly so. How can a program or the system predict that I'll signal
end-of-file with next key sequence without blocking for the key codes to
arrive?
In the case in question, the system may know that stdin is not
connected to anything, so that any read would result in EOF. I think
it would be reasonable for a system to consider that if stdin isn't
connected to anything then an error has already occurred, and make
ferror(stdin) return true. But I don't know of any implementations
that do that - they just let you get the error when you do the read.
[On unix, running a program with stdin unconnected will result in
bizarre results if the program fopen()s a file and then attempts to
read from stdin, because the opened file will have file descriptor 0
and therefore be attached to stdin as well as the FILE * returned from
fopen().]
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Nikos Chantziaras wrote:
>Yes. But AFAIK, feof() checks the EOF indicator of a stream, and that
indicator is only set after actually trying to read from the stream.
feof(stdin) therefore would never return non-zero right at the start of
the program (when nothing has been read from stdin yet).
Correct. The following code fragment may or not do what you need, it
does not discriminate between a stream at EOF (not an error) and other
possible error conditions: stream invalid, not-open, etc.
#include <stdio.h>
int stream_has_some_data(FILE *stream)
{
int c = getc(stream);
if (c != EOF)
{
ungetc(c, stream); /* add check for errors */
return 1;
}
return 0;
}
(Sorry if this is an almost duplicate post. I canceled a previous
one, but ...)
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
In article <gb********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.netwrote:
>On the other hand, I just read on the OpenGroup man page for exec that
"If file descriptors 0, 1, and 2 would otherwise be closed after a
successful call to one of the exec family of functions, ... <snip...
implementations may open an unspecified file for each of these file
descriptors in the new process image."
Ah, presumably that is to avoid the strange behaviour I mentioned.
But none of the unixes I have to hand seem to do it.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Nikos Chantziaras wrote On 08/01/07 11:03,:
Eric Sosman wrote:
>>Nikos Chantziaras wrote On 08/01/07 09:50,:
>>>Is there a way to check if the current process has an stdin handle? In
the win32 API, one can do:
_eof(_fileno(stdin))
Crucial here is that the above doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
What is a "stdin handle," and what does it mean
for a process to "have" one?
In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action. They will remain so
until the program ends, or you close them, or an I/O
error occurs. I/O errors can be detected by using the
ferror() function. If you close any of these streams
you ought to know you've done it. Writing code to
determine the streams' state after the program containing
the code exits is left as an exercise for the reader ;-)
I formulated it a bit "weird". It's porting work, btw, (from win32 to
"as portable as possible") so not everything is 100% clear to even me,
since I'm not the implementor of the original; I just do the porting ;)
In any event, the original is "_eof(_fileno(stdin))" which checks for
EOF on stdin without blocking. In other words, it allows for knowing
beforehand if EOF would be returned when attempting to read from stdin
without actually reading.
It's certainly not possible in portable C, and I don't
see how it could be possible at all:
int will_get_eof = _eof(_fileno(stdin));
int got_eof;
printf ("Carnac the Magnificent predicts "
"that you %s about to press ^Z\n",
will_get_eof ? "are" : "are not");
(void)getchar();
got_eof = feof(stdin);
if ( (got_eof == 0) == (will_get_eof == 0) )
printf ("Carnac was right, as always.\n");
else
printf ("May the fleas of a thousand camels "
"take refuge in your shorts.\n");
-- Er*********@sun.com
In article <1u********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.netwrote:
>Correct. The following code fragment may or not do what you need, it
does not discriminate between a stream at EOF (not an error) and other
possible error conditions: stream invalid, not-open, etc.
#include <stdio.h>
int stream_has_some_data(FILE *stream)
{
int c = getc(stream);
if (c != EOF)
{
ungetc(c, stream); /* add check for errors */
return 1;
}
return 0;
}
This has the problem (for the OP) that it may block for an arbitrarily
long time if the stream is connected to, for example, a terminal.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
santosh said:
Richard Tobin wrote:
>In article <1185978665.736059@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
>> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
Theoretically perhaps, but are there any operating systems where that
is in fact guaranteed?
Doesn't the C Standard require it to be so?
In hosted environments, yes it does. But not in freestanding
environments, of course. For example, typical Windows GUI programs will
not have these streams available to them at startup.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
>Eric Sosman <Er*********@sun.comwrote:
> In a hosted environment, at the moment main() is
first called the three streams stdin, stdout, stderr
are open and ready for action.
In article <gb********************************@4ax.com>
Roberto Waltman <us****@rwaltman.netwrote:
>Is this guaranteed?
Yes, it is guaranteed. However, some might consider this a bit hollow,
because:
>I though a process can be started with any or all
of the standard streams closed.
It can indeed, on at least some systems. The C library on those
systems may, or may not, "paper over" this problem (e.g., by opening
/dev/null to fill in descriptors 0, 1, and 2). Let us suppose
further that we have one that does *not* do so.
In this particular case, what this means is that:
# this command closes fd 0 through 2 when starting ./foo
$ ./foo <&- >&- 2>&-
runs "foo" in something other than a "hosted environment".
>What does the C standard require? (I couldn't find an answer on N1124)
It requires a "hosted environment" to provide pre-opened stdin,
stdout, and stderr. If you use a "non-hosted environment" to run
your program, by doing the above for instance, this is your fault,
not the Standards, nor the system's. :-)
("Secure" programs, on the systems I alluded to above, must make
sure they do not assume that fd 0 through 2 are open. Thus, writing
setuid programs is nontrivial -- but the C standard cannot help
here since "setuid programs" is not even a Standard C concept.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
in comp.lang.c i read:
>Nikos Chantziaras wrote:
>>Is there a way to check if the current process has an stdin handle?
>>Crucial here is that [it] doesn't block. Is there a standard way
to do the same without resorting to OS-specific API calls?
no.
>The following code does not discriminate between a stream at EOF and
other possible error conditions. (stream invalid, not-open, etc.)
int c = getc(stream);
[...]
ungetc(c, stream); /* add check for errors */
the getc might block, on systems where that concept exists.
--
a signature
Nikos Chantziaras <re****@arcor.dewrote:
# Hello.
#
# Is there a way to check if the current process has an stdin handle? In
# the win32 API, one can do:
#
# _eof(_fileno(stdin))
#
# Crucial here is that the above doesn't block. Is there a standard way
# to do the same without resorting to OS-specific API calls?
I doubt you come up with definitions of the terms you are using
which will be the same on all C implemented platforms; this
strongly suggests you will not find an ANSI C solution. The
alternative is to research each platform you are interested in
and make a separate system specific implementation of a function.
Also there are multiplatform libraries that can do much of this
for you already. They might not run on all possible platforms,
but they're likely to run on every platform you're interested in.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
This is one wacky game show.
SM Ryan wrote:
Nikos Chantziaras <re****@arcor.dewrote:
# Hello.
#
# Is there a way to check if the current process has an stdin handle? In
# the win32 API, one can do:
#
# _eof(_fileno(stdin))
#
# Crucial here is that the above doesn't block. Is there a standard way
# to do the same without resorting to OS-specific API calls?
I doubt you come up with definitions of the terms you are using
which will be the same on all C implemented platforms; this
strongly suggests you will not find an ANSI C solution. The
alternative is to research each platform you are interested in
and make a separate system specific implementation of a function.
Also there are multiplatform libraries that can do much of this
for you already. They might not run on all possible platforms,
but they're likely to run on every platform you're interested in.
I just went with "select(1, 0, 0, 0, &timeout) == -1", but that's
outside the realm of this newsgroup.
In article <f8**********@volcano1.grnet.gr>,
Nikos Chantziaras <re****@arcor.dewrote:
>SM Ryan wrote:
>Nikos Chantziaras <re****@arcor.dewrote:
# Is there a way to check if the current process has an stdin handle?
>I just went with "select(1, 0, 0, 0, &timeout) == -1", but that's
outside the realm of this newsgroup.
[OT] http://www.opengroup.org/onlinepubs/...sh/select.html
The 2nd, 3rd, and 4th arguments to select() are of type fd_set
which need not be an integral type. You need to use FD_ZERO()
and FD_SET() to create an fd_set that designates stdin .
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
Walter Roberson wrote:
In article <f8**********@volcano1.grnet.gr>,
Nikos Chantziaras <re****@arcor.dewrote:
>SM Ryan wrote:
>>Nikos Chantziaras <re****@arcor.dewrote:
# Is there a way to check if the current process has an stdin handle?
>I just went with "select(1, 0, 0, 0, &timeout) == -1", but that's
outside the realm of this newsgroup.
[OT]
http://www.opengroup.org/onlinepubs/...sh/select.html
The 2nd, 3rd, and 4th arguments to select() are of type fd_set
which need not be an integral type. You need to use FD_ZERO()
and FD_SET() to create an fd_set that designates stdin .
Those arguments can be NULL (i used 0 because I'm calling the function
from C++ actually, and I got into the habit of using 0 instead of NULL
in C++ since I perceive it are "more readable").
stdin is guaranteed to have a file descriptor of 0 at program start, so
the first argument is 0+1 (or just 1).
In article <f8**********@volcano1.grnet.gr>,
Nikos Chantziaras <re****@arcor.dewrote:
>>I just went with "select(1, 0, 0, 0, &timeout) == -1", but that's
outside the realm of this newsgroup.
>The 2nd, 3rd, and 4th arguments to select() are of type fd_set
which need not be an integral type. You need to use FD_ZERO()
and FD_SET() to create an fd_set that designates stdin .
>Those arguments can be NULL
But you still have to pass a "readfds" argument with bit zero set, to
check file descriptor zero. A null value means you're not interested
in any descriptors.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard Tobin wrote:
In article <f8**********@volcano1.grnet.gr>,
Nikos Chantziaras <re****@arcor.dewrote:
>>>I just went with "select(1, 0, 0, 0, &timeout) == -1"
The 2nd, 3rd, and 4th arguments to select() are of type fd_set
which need not be an integral type. You need to use FD_ZERO()
and FD_SET() to create an fd_set that designates stdin .
Those arguments can be NULL
But you still have to pass a "readfds" argument with bit zero set, to
check file descriptor zero. A null value means you're not interested
in any descriptors.
Oops. Changed to:
FD_ZERO(&rfds);
FD_SET(0, &rfds);
return select(1, &rfds, 0, 0, &timeout) == -1;
Nikos Chantziaras wrote On 08/02/07 12:31,:
Walter Roberson wrote:
>>In article <f8**********@volcano1.grnet.gr>,
Nikos Chantziaras <re****@arcor.dewrote:
>>>SM Ryan wrote:
Nikos Chantziaras <re****@arcor.dewrote:
# Is there a way to check if the current process has an stdin handle?
>>>I just went with "select(1, 0, 0, 0, &timeout) == -1", but that's
outside the realm of this newsgroup.
[OT]
http://www.opengroup.org/onlinepubs/...sh/select.html
The 2nd, 3rd, and 4th arguments to select() are of type fd_set
which need not be an integral type. You need to use FD_ZERO()
and FD_SET() to create an fd_set that designates stdin .
Those arguments can be NULL (i used 0 because I'm calling the function
from C++ actually, and I got into the habit of using 0 instead of NULL
in C++ since I perceive it are "more readable").
stdin is guaranteed to have a file descriptor of 0 at program start, so
the first argument is 0+1 (or just 1).
<off-topic>
Be aware that buffering can lead to a wrong answer.
You call select() and learn that there's input available,
so you call getc() to read the first byte. The library
reads everything file descriptor 0 has to offer, stuffing
all forty-two bytes in an internal buffer and returning
the first of them as the value of getc(). Now you call
select() again, and you find that there's no more input
available on FD 0 -- it has already been read and is now
sitting in the buffer waiting for you to retrieve it ...
Suggested solutions (one mildly topical):
- Use setvbuf() to put the stdin FILE* stream in
unbuffered mode. Not particularly wonderful if
there's a lot of input ...
- Use read() instead of getc() and friends. *Never*
use stdin at all; use only file descriptor 0. For
extra safety, consider dup()ing FD 0, fclose()ing
stdin, and using the dup()ed FD instead.
</off-topic>
-- Er*********@sun.com
On 2007-08-01 16:25, Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
In article <gb********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.netwrote:
>>On the other hand, I just read on the OpenGroup man page for exec that
"If file descriptors 0, 1, and 2 would otherwise be closed after a
successful call to one of the exec family of functions, ... <snip...
implementations may open an unspecified file for each of these file
descriptors in the new process image."
Ah, presumably that is to avoid the strange behaviour I mentioned.
But none of the unixes I have to hand seem to do it.
Linux does, but only if the effective uid is different from the real
uid.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kpohl |
last post by:
Hi!
It would be great if anyone could help me with this problem:
I want to check the syntax of my php code. Therefore I use the command
line function PHP -l, the structure is similar to the...
|
by: Stephen Boulet |
last post by:
This is wierd. I can launch and kill a process in windows, but only if I do
it in the same script.
Just using xemacs as an example, I can launch it like so:
import os, win32api, sys,os.path...
|
by: Peter Åstrand |
last post by:
There's a new PEP available:
PEP 324: popen5 - New POSIX process module
A copy is included below. Comments are appreciated.
----
PEP: 324
Title: popen5 - New POSIX process module
|
by: Mike M |
last post by:
Is it possible? In the parent process, I have a socket that binds,
listens and then accepts new connections (which creates new sockets in
the process). I want to be able to pass some of these new...
|
by: serge calderara |
last post by:
Dear all,
I have an application which is suppose to start another executable process.
As soon as that process is running, I need to retrive its handle. The
problem of the particular process I am...
|
by: moosdau |
last post by:
my code:
do
{
printf("please input the dividend and the divisor.\n");
if(!scanf("%d%d",&dend,&dor))
{
temp1=1;
fflush(stdin);
}
else
|
by: Samuel A. Falvo II |
last post by:
I have a shell script script.sh that launches a Java process in the
background using the &-operator, like so:
#!/bin/bash
java ... arguments here ... &
In my Python code, I want to invoke...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
