Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.os.misc
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <1991Jan17.061022.9863@Think.COM>
Date: 17 Jan 91 06:10:22 GMT
References: <1991Jan16.063253.2834681@locus.com> <1991Jan16.182106.1758@Think.COM> <1991Jan16.222155.2836960@locus.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 27

In article <1991Jan16.222155.2836960@locus.com> dana@locus.com (Dana H. Myers) writes:
>In article <1991Jan16.182106.1758@Think.COM> barmar@think.com (Barry Margolin) writes:
>>I'm getting tired of repeatedly seeing this argument.  How do you know that
>>*any* program follows common conventions?  For instance, how would one know
>>that a given app reads stdin and writes stdout
>   The shell does not enforce any conventions on how a program deals
>with I/O. This, as you point out, leads to ambiguity. I don't, however,
>see how this speaks against my original argument

My point was that there is a claim that users would be confused and would
have to memorize which commands behave in which way.  Does the current
situation with regard to I/O confuse users?  Have you memorized which
commands can be filters and which can't?  I suspect the answer is "no" to
both questions.  I can only think of two commands that don't behave in the
obvious way: passwd(1) reads from /dev/tty rather than stdin, for security
reasons (although now that many systems have ptys, this reasoning is bogus,
and it should probably be fixed); and stty(1) operates on stdin in System
V, but stdout in BSD (System V's behavior seems more "obvious", as it
prints its output to stdout, while BSD prints the non-error output to
stdout, but it would probably make things much easier if they also accepted
filename arguments on the command line).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar