Mail Archives: djgpp/1998/03/30/06:12:47
On Mon, 30 Mar 1998, Eric Gillespie wrote:
> Yeah, I agree, but only in part - I do ACTUALLY want to print the garbage
> heading through stdin, but it turns out the way I've been doing it, the
> stdin can't be set to O_BINARY anyway 8-(, at least not in this situation:
>
> cat strayfile.binary | hexdump
>
> As you probably have figured out, I need the cat program to open stdin in
> O_BINARY, not just hexdump.
Why do you need `cat's *stdin* in binary? Isn't binary stdout enough?
If it is, then `cat' already does that automatically when its stdout
us redirected to a file or a pipe. So I don't think you will see any
problems in the above example.
> I am also having problems when using stdin
> and then asking for a getch() directly after checking kbhit() - the
> program locks up, though getch will work in other situations while using
> stdin.
This is exactly one of the ``nasty side-effects'' I were talking
about. I think that stdin should only be switched to binary when it
is NOT a console. If you have an example of a case where you need the
console to use binary I/O in a filter-style program like `cat' and
`hexdump', please describe that case.
> I found out I could quite happily substitute getxkey for getch - it
> means it's not portable, but then I had never intended it to be (at
> least not until I port this little so and so to Linux or something...)
The portable way is to use `read' for reading the console (after
switching it to binary mode), and use `select' to check whether a key
has been hit.
Note that the above is an example of the only class of programs known
to me which *do* need to switch stdin to binary mode. Those are the
programs which interact with the user by reading single keystrokes.
Typically, these are editors, debuggers, and other programs which
feature a user interface through the keyboard.
- Raw text -