Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site onfcanim.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: Shell history
Message-ID: <14797@onfcanim.UUCP>
Date: Tue, 18-Mar-86 23:57:09 EST
Article-I.D.: onfcanim.14797
Posted: Tue Mar 18 23:57:09 1986
Date-Received: Wed, 19-Mar-86 05:33:02 EST
References: <1512@brl-smoke.ARPA> <140@umcp-cs.UUCP> <542@mtxinu.UUCP> <71@cascade.ARPA> <214@isieng.UUCP> <358@hropus.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: ONF, Montreal
Lines: 23

People have mentioned that the Bourne shell had better "programming"
(flow of control) structures than the old v6 shell.  Very true - it made
writing non-trivial shell files at least a bit saner job.

But nobody has mentioned what I considered the biggest incentive to change
over.  In the old, v6 shell, the standard input of any commands that were
invoked from a shell script was the shell script itself.  This was sometimes
convenient; that's how the control structures were implemented, and you could
put things like "ed" commands directly into the script (as long as the
program you were calling also read its input one character at a time - ed did).
But it meant that you could *not* write shell scripts that were to be
used as filters, even if their execute bit was set, since the standard input
of the shell at the time it was forked was no longer available.

The thing the Bourne shell did for the world was to start all of the child
processes invoked from a shell file with their standard input, output, and
error streams the same as the shell itself.  Thus, you could write filters,
and the desire to build new software out of already-existing pieces no
longer conflicted with the desire to make everything a filter if it could
possibly be used that way.

Look around your favourite UNIX system.  See how many shell-script filters
there are.