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