Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.os.misc,comp.unix.wizards
Subject: Re: Command interfaces
Message-ID: <5565@oberon.USC.EDU>
Date: Wed, 31-Dec-69 18:59:59 EST
Article-I.D.: oberon.5565
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Sun, 13-Dec-87 09:29:02 EST
References: <1257@boulder.Colorado.EDU> <6840002@hpcllmv.HP.COM> <9555@mimsy.UUCP> <798@rocky.STANFORD.EDU> <432@cresswell.quintus.UUCP> <3161@psuvax1.psu.edu>
Sender: nobody@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 100
Xref: mnetor comp.os.misc:337 comp.unix.wizards:5916

In article <3161@psuvax1.psu.edu> schwartz@gondor.psu.edu (Scott E. Schwartz) writes:
>In article <432@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>    PR1MOS:
[comments about pre-rev 14 primos, which is about as modern as unix
version 3 or VMS 1.0.  Do you wonder why I ignore complaints about its
command interface?]

(Primos 21.0.1 is the latest supported release I have used.  Due to
non-disclosure agreements, I can't discuss current beta testing, if
any.)

>>	If SEG understands wildcards this is the first I've heard of it.
>I last used primos at rev 20.  SEG didn't know about wildcards

SEG doesn't know about wildcards.  Wildcards are handled for SEG by
the Primos command processor.  (There is no way to turn off wildcard
expantion to a program loaded with SEG other than telling the command
processor not to expand them, such as quoting the argument.)
(Wildcards have been part of the primos command processor since 19.0,
about 5 years.)

>then either, but there is a new utility called "BIND" that makes
>(new) EPF style runfiles.  (These work like primos "internal"
>commands.) BIND takes command line options, unlike SED.
>Part of the magic of BIND is it allows you to specify what command
>line objects (i.e. wildcards) are expanded by the command processor
>when the BINDee is invoked.

(Bind has been supported since primos 19.4)

>One catch when talking about primos wildcards is that they
>are treated in a fundamentaly different way than unix wildcards.
>The command line "cc @.c" with files a.c b.c  is equivalent to 
>	cc a.c
>	cc b.c
>rather than "cc a.c b.c".  That is, the command processor
>iterates over wildcards rather than expanding them.  To get unix
>style behavior, you have to use the Multics-ism "cc [wild @.c]"
>or use BIND to tell the command processor not to expand wildcards
>for cc.  Primos supplies library routines to search directoies
>using wildcards.

You can also specify to bind that the wildcard will only match files
not directories, that the user should be queried for each file on
wildcard matches unless the -novfy option is given, (used by delete)
which argument name matching is to be performed against, etc.

This is an example of the difference between command interfaces
between unix and primos.  Most primos commands will only process one
file per run, (including the C compiler) so the primos wildcard
expantion matches what the primos commands expect.  Only those
commands which have some use for processing multiple files together
(ld and emacs are examples) need to turn off the command processor
wildcard expantion and do their own.  (Of course system calls to do the
wildcard expantion are available.)  For programs like delete it
doesn't matter to the user how it is done, and for programs like copy
and rename the primos way is more powerfull because of name generation.

When talking about primos wildcards, you should remember that they are
in general more powerfull that unix wildcards.  Besides + (match any
single character) @ (match a sequence of 0 or more characters not
containing .) and @@ (match any sequence), there are facilities to do
name genearation and iteration.

For example, how would you do the equivelent of this in unix:

cmpf *>old>@@.(c,h) == -report ==.+cmpf -file

(Explanation: compare all files in the old sub-directory ending in .c or
.h with the file of the same name in the current directory, and put
the output in the file of the same name with .cmpf appended.  Non-files
(directories and segment directories) ending in .c or .h are ignored.
[I do prefer the output of diff -c to that of cmpf, but that isn't
what I'm talking about here.]

>Note that is would be easy to add this kind of functionality
>to unix... just add more bits to the inode structure, 

These bits should be part of the program object, in my opinion.
Shells that understand them can notice the new magic number and look
at some flag word to figure out what wildcard expantion to do.

>st_dowild say.  Then have the shell look at them before
>expanding wildcards.  It will never catch on, though :-)

>For the record, after several years of using primos, it is clear
>to me that the unix scheme is sufficiently clearer and simpler 
>so as to outweigh many of the arguments against having the shell
>to globbing.  Nothing is perfect, but in general unix does it better.

After several years of using primos, it is clear to me the unix way of
handling wildcards is much less powerfull.  However, many users will
never bother to figure out more than the minimum needed to do their
job.  It is clear to me that power, ease of use, etc. have almost no
relation to how operating systems are chosen anyway.
--
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1@ecla.usc.edu
			oberon!fns1!info-prime-request