Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <791@mcgill-vision.UUCP>
Date: Thu, 4-Jun-87 18:36:59 EDT
Article-I.D.: mcgill-v.791
Posted: Thu Jun  4 18:36:59 1987
Date-Received: Sat, 13-Jun-87 11:24:47 EDT
References: <7359@brl-adm.ARPA> <983@bobkat.UUCP> <5872@brl-smoke.ARPA> <684@bsu-cs.UUCP>
Organization: McGill University, Montreal
Lines: 26

In article <684@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> In article <5872@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 
> explains the need for a /dev/stdin thus:

>> ....any place where the code is set up to deal with a filename but
>> you might prefer to use the output end of a pipe (for example).

> I see a potential problem here.  Programs that won't let you read
> from standard input will frequently attempt to do seeks within the
> input file.

That's their problem. :-)

A program that expects to do seeks should ensure that the object can
seek, not just prohibit standard input.  Suppose you use gave it
/dev/tty?  There's something, on BSD at least, called fstat(), which
performs a stat() on the object pointed to by a file descriptor.  Even
better, maybe, would be to try a seek and die if it fails.

When I wrote a program that expected to seek, I just punted: ignore the
issue, and note in the documentation that it expects seeks to work!
(Yes, this is suboptimal.  To put it mildly.)

					der Mouse

				(mouse@mcgill-vision.uucp)