Xref: utzoo comp.arch:20577 comp.misc:11328
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.arch,comp.misc
Subject: Re: Computers for users not programmers
Message-ID: <1991Feb04.213510.5832@chinet.chi.il.us>
Date: 4 Feb 91 21:35:10 GMT
References: <13252@lanl.gov> <3169@crdos1.crd.ge.COM> <5038@mentor.cc.purdue.edu>
Organization: Chinet - Chicago Public Access UNIX
Lines: 51

In article <5038@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>>   So what programs under MS-DOS, AmigaDOS, MaxIntosh, VMS, AOS, CMS and
>> JPL correspond to awk, sed, yacc, diff, and grep? Other than VMS, which
>> has a diff which produces an output which is only human readable, and a
>> search command which lacks powerful pattern matching, the capabilities
>> seem... well *missing* is the first word which comes to mind.

>What do these tools have to do with the UNIX operating system?  Possibly
>there are some legal restrictions in some cases, but I believe most of
>these are public domain.  At most, interfaces would have to be rewritten.

What unix provides is the ability to easily tie these tools together
so that you can combine the operations of the individual tools.  How
would you propose to get an equally easy-to-use interface in a
single-tasking environment like MSDOS or CMS?

>The hardware provides the capabilities.  As far as possible, software
>should allow the user access to these capabilities.  Except for security
>restrictions, and possibly some restrictions to prevent physical damage
>to the machine, software should allow whatever hardware allows, instead
>of restricting it.

Exactly, and if you are inclined toward the toolbox approach, that
means the OS should provide multi-tasking, virtual memory, and
an efficient means to connect the output of one program to the input
of another.  Also, you need a quick and easy way to automate any
portion of a task that the operator finds to be repetitive.

>As far as grep is concerned, the only UNIX part in the interface is handling
>file access and the ability to display file names.  I agree that any 
>operating system needs this, and the more flexible the better.  This
>means reading directories, and the possibility of accessing files only
>found by reading directories.  That is part of the operating system.
>Getting line numbers, etc., is not.

Wrong!  The useful function has nothing to do with directory reading
because it doesn't do any (at least under unix where the shell normally
expands wildcard filenames).  It has much more to do with the fact
that grep can be used to parse the output of any other program that
generates a stream of lines, and in turn its output (and exit status
indicating sucess of a match) can be used by any other program.

While it is possible to approximate the functionality of pipes using
temporary files, there are many situations where this is impractical.
For example the total amount of data may be larger than the available
storage, or you may wish to interrupt the processing as soon as
the first output appears.

Les Mikesell
  les@chinet.chi.il.us