Prev: a.out and ELF file formats
Next: Is there a C library function to open a file found in a path?
From: Poster Matt on 1 Mar 2010 16:59
Barry Margolin wrote:
> If you want stdin to revert to its previous value when the end of the
> file is reached, you can invoke your program as follows:
>
> cat filename - | program
>
> Supplying a filename of "-" to cat refers to cat's stdin.
>
> However, if your program reads to EOF, and then expects to read the
> answer to a question from the user, the above won't work, because your
> program won't see EOF when the end of the file is reached.


Thanks for the advise Barry.
From: Poster Matt on 1 Mar 2010 17:01
Eric Sosman wrote:
> On 3/1/2010 11:49 AM, Poster Matt wrote:
>> [...]
>> By the way is reading '/dev/tty' as keyboard input guaranteed on all
>> Unix/Linux systems?
>
> Yes, sort of. /dev/tty is (an alias for) the process'
> "controlling terminal." That device might be a tty with a
> keyboard, or a pty, or a serial line with unknown gadgetry
> at the far end, or ... It's Unix' notion of a device that
> someone/something can use to "control" the process.
>
> However, a process might have no "controlling terminal"
> at all; this is quite commonly the case for daemons, and can
> also be true for other processes. So in that sense, No: the
> existence of /dev/tty is not guaranteed. (Off-hand, I don't
> recall whether an attempt to open /dev/tty when there's no
> controlling terminal simply fails, or opens /dev/null instead;
> look it up for yourself.) In any event, there do exist Unix
> processes that are not associated with any interactive devices
> at all -- which would make "user confirmation" difficult ...

Ok, thanks again Eric. I really appreciate your help. Thanks for your
informative and helpful replies.

Regards,

Matt
From: Poster Matt on 1 Mar 2010 17:30
Eric Sosman wrote:
>
> existence of /dev/tty is not guaranteed. (Off-hand, I don't
> recall whether an attempt to open /dev/tty when there's no
> controlling terminal simply fails, or opens /dev/null instead;
> look it up for yourself.)

If an attempt to open /dev/tty is made when there is no controlling terminal
then the open will fail.

Just thought I'd mention it since I found the answer. :)
From: Keith Thompson on 1 Mar 2010 20:20
Poster Matt <postermatt(a)no_spam_for_me.org> writes:
[...]
> if (isatty(fileno(stdin)) == 0)
> stdin is not a terminal device - search stdin for the expected data.
>
> then later when getting the user confirmation:
>
> int c;
>
> // stdin is a terminal device, read a character from stdin.
> if (isatty(fileno(stdin)) == 1)
> c = getchar();
[...]

A style point: isatty() returns a result that's logically either true
or false. Comparing this result to 0 or one is unnecessary and, in my
opinion, obfuscates the code. Try this:

if (! isatty(fileno(stdin))) ...

if (isatty(fileno(stdin))) ...

Note that some functions that return boolean results can return any
non-zero value for true. For such functions, comparing the result
to 1 can give you incorrect behavior. (isatty() happens to return
just 0 or 1, but it's not wise to depend on that.)

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Gordon Burditt on 2 Mar 2010 06:10
>> The problem is now how do I achieve that behaviour? When the program
>> starts, check if there's been a file redirected from the command line,
>> if so read that file storing relevant data, then -either way- make sure
>> I can read a character entered by the user from the terminal/keyboard to
>> give confirmation that proceeding is ok?

Some programs, I believe more(1) was one of them, solve this issue
by *reading* *standard error* for user commands like proceeding to
the next screen.

Be careful about how you deal with redirection: you can have
multiple redirections of stdin to and away from keyboards, and it's
not guaranteed to be the same keyboard. You probably only want to
worry about the latest redirection and what you've got as stdin
right now. Questions: is isatty() true on a serial printer? A
parallel printer? How about a USB printer that looks like a serial
printer? Does a serial printer *have* a keyboard? Does a serial
GPS device (or a USB device set up to look like a serial port) have
a keyboard? (It seems to have someone typing on it continuously).


Avoid /dev/tty if the program isn't so hopelessly interactive it
can't possibly work without interaction. You cannot open /dev/tty
if the program has no controlling terminal, which will happen from
cron and at jobs and stuff invoked from daemons. /dev/tty will
work if the program is running attached to a pty. Although you
might think you'll never run the program from cron, it's needed
often. Note that in at least some versions, getpass() and programs
like su(1) read from /dev/tty, not stdin, and trying to run them
from cron can cause silent failure.

>Is reading the file '/dev/tty' as keyboard input guaranteed on all Unix/Linux
>systems?

No, not for programs with no control terminal.

Occasionally an administrator or some program will screw up and put
restrictive permissions on /dev/tty or delete it, but that's just
a misconfiguration.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: a.out and ELF file formats
Next: Is there a C library function to open a file found in a path?