Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!tut.cis.ohio-state.edu!rutgers!att!cbnewsc!nichols
From: nichols@cbnewsc.ATT.COM (robert.k.nichols)
Newsgroups: comp.unix.wizards
Subject: Re: Detecting Pipe Using Bourne Shell
Summary: a terminal can be hidden by a filter
Message-ID: <457@cbnewsc.ATT.COM>
Date: 9 Apr 89 01:04:11 GMT
References: <18992@adm.BRL.MIL> <999@philmds.UUCP>
Reply-To: nichols@iexist.ATT.COM (bob.nichols)
Followup-To: <999@philmds.UUCP>
Organization: AT&T Bell Laboratories
Lines: 27

In article <999@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>
>if test -t 0
>then
>    # stdin from terminal
>else
>    # stdin not from terminal
>fi

Programs and procedures that use this means of distinguishing their
input source are one of my pet peeves.  Sometimes I want to interpose an
editing filter between my terminal and stdin of some program, giving me
the ability to repeat previous input lines (perhaps with modifications),
include the contents of an existing file in the input stream, etc.  Any
program that uses "test -t 0" (or an equivalent) will break in such an
environment.

Acceptable alternatives are:
	1.  Use an argument of "-" to mean "read stdin as though it were
	    a file."
	2.  Go ahead and use the "test -t 0" mechanism, but provide for a
	    "-i" flag to force interactive mode when something is hiding
	    the fact that stdin is really a terminal.
-- 
.sig included a no extra charge.           |  Disclaimer: My mind is my own.
Cute quotes and batteries sold separately. |  Copyright 1989 Robert K. Nichols.
                                           |  For USENET use only.