Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!aplcen!jhunix!ins_ampm
From: ins_ampm@jhunix.UUCP (Michael P McKenna)
Newsgroups: net.micro.amiga
Subject: Re: More unwanted opinions on Amiga DOS
Message-ID: <1628@jhunix.UUCP>
Date: Wed, 29-Jan-86 00:32:42 EST
Article-I.D.: jhunix.1628
Posted: Wed Jan 29 00:32:42 1986
Date-Received: Sat, 1-Feb-86 02:03:00 EST
References: <1041@caip.RUTGERS.EDU> <373@3comvax.UUCP>
Reply-To: ins_ampm@jhunix.ARPA (Michael P McKenna)
Distribution: net
Organization: Johns Hopkins Univ. Computing Ctr.
Lines: 91
Keywords: pipes, wildcards
Summary: explanation of pipes  --  hit 'n' NOW  Unix hackers

In article <373@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes:
>
>
>I am no Unix expert, but aren't ports and pipes (between processes) the
>same (sorry, but I am ignorant if they aren't).  If you refer to pipes on
>the command line, I am glad tht Amiga left them out rather than tying up
>RAM or using floppies for the piped data.  I have these pipes available to
>me under MS DOS all day, but I rarely use them and see no absolute need for
>them.
>
Most of the following is an explanation of pipes.  If you are 
experienced with Unix you will probably want to skip it.

Ports and pipes are quite definitely NOT the same.  Message ports on the
Amiga provide for interprocess communication, i.e. for two (or more)
processes to 'talk' to each other.  Pipes take the output of one
command and use it as the input of the next command, IN A WAY THAT IS
TRANSPARENT TO THE COMMANDS THEMSELVES.  It's that last bit that is
important.  Pipes provide a way of tying simple programs together to
do more complex operations.  This is a key part of the Unix philosophy.
Ideally each command does one task and does it well.  For example consider
the Unix commands 'pr' and 'lp'.  The command 'pr -k foofile' produces
the contents of foofile on standard output in k columns.  The command
'lp foofile' sends foofile to a line printer, if no file is given
then standard input is used.  Now if we type 'pr -3 foofile | lp'
then the pr command produces foofile in 3 columns, this output is
sent to the lp command which prints it.  One could argue that a column
option could be added to lp rather than using a pipe but there are good
 reasons for not doing this.

   1. It makes the lp program larger, and therefore harder to maintain.

   2. lp has options for controlling destination printer, number of
      copies, etc.  Providing many options to a command makes it 
      harder for the user to remember what they do.

   3. The user might want multi-column output for other commands.
      Which is simpler, adding a multi-column output to every command
      where it might be wanted or allowing the user to pipeline commands?

As a another short example, should every command that produces output
have a sort option?  Isn't it easier to pipe the output to a sort 
routine?  Each command is then smaller and the user has less to
remember.
A more experienced user might notice that we can pipeline operations
by using I/O redirection, i.e. instead of  'pr -k foofile | lp'
we could type 'pr -k foofile >temp'
              'lp <temp' (or in this case 'lp temp')

This is not quite the same thing though.  In a pipeline all commands
run simultaneously (when their respective input is available).  Also
with a pipe you type the command in and forget about it.  Using I/O
redirection, you have to type a new command for each step (more than
just two commands can be included in a pipeline).

So why aren't pipes in AmigaDOS?  I suspect it is because of memory
limitations.  I don't know how much memory a pipe uses but
consider that there is overhead in setting it up, plus the actual
buffer area, plus the added size of the operating system.  

>Someone posted a source to unix-style ls for the Amiga, including wildcards,
>etc.  So who cares if the Amiga doesn't do wildcards nice, it does now!!
>This ls also sorts the directories by date and time and alphabetically too!
>This ought to make the disk directory format less of an issue (although it
>does take a while to enumerate (expand) wildcards).
>

NOT THE SAME THING!  In Unix the shell expands wildcards, NOT the
individual command.  In fact there is no way for the command to know
that a wildcard was used in invoking it!  This means that:

     1. A consistent wildcard system is used for all commands.  Since
        the shell, not the commands expand the wildcards the same 
        wildcards apply to every command.

     2. When you write a program you don't have to do any wildcard
        expansion, the system handles it for you.

>Consider this - the Amiga is making a new standard that in most ways is
>better than the old ones (unix and MS Dos included here).  To me it is
>no worse than Unix to program for, and light years better than MS DOS.
>Given time, the Amiga will mature into something that might make us all
>(except for the religious) forget unix. 

Agreed, but only if users point out the shortcomings of the current
system and offer constructive criticism.  I consider the lack of
pipes and wildcards a deficiency in an otherwise nice operating system,
and hope that they will be added in the future.


                                                      Dwight S. Wilson