blarson@skat.usc.edu (Bob Larson) (01/01/70)
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
chris@mimsy.UUCP (Chris Torek) (12/08/87)
In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >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. `sh' is a programming language, and can be shown to be Turing equivalent (proof by vigourous handwaving), so unless the Pr1me CLI can also be shown to be Turing equivalent, the Unix shell interface is more powerful. for i in old/*.[ch]; do # all files in the old subdir.. if [ -f $i ]; then # ignore directories named .c or .h j=`echo $i | sed 's,.*,,'` # get name without leading dir diff $i $j > $j.cmpf # and compare, output in `.cmpf' fi done (I never said it was more concise. :-) ) This sort of thing, like the `rename *.bar .baz' that others are so proud of :-) , seems to be desired only rarely; in such cases, shell `for' loops, or programs like one posted sometime last year[1], do the trick quite easily. ----- [1] Program name and author forgotten, but basically, it ran a command iteratively, so that *.bar could be renamed to *.baz with a syntax like `doit mv \*.bar =.baz'. It may have been posted more than a year ago. At any rate, I did not save it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
g-rh@cca.CCA.COM (Richard Harter) (12/09/87)
In article <9679@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >`sh' is a programming language, and can be shown to be Turing >equivalent (proof by vigourous handwaving), so unless the Pr1me >CLI can also be shown to be Turing equivalent, the Unix shell >interface is more powerful. > Although I have much respect for Chris, this is rather wide of the mark. It takes very little to be Turing equivalent; CLI is also Turing equivalent (proof by more vigorous handwaving). More to the point in discussing languages are the classes of tasks that can be programmed readily in a language. The claim at hand is that CLI is more powerful and expressive that sh, i.e. the class of tasks that it can handle easily and economicly is greater. Having worked with both (and not being willing to claim expertise in either) I will only say that this is not immediately obvious to me. Each strikes me as being baroque in its own fashion. > >This sort of thing, like the `rename *.bar .baz' that others are >so proud of :-) , seems to be desired only rarely; in such cases, >shell `for' loops, or programs like one posted sometime last year[1], >do the trick quite easily. > 'seems to desired only rarely' is a red flag. Within a particular language one very tends to do that which can be done easily within the language. For example, FORTRAN has no natural mechanism for recursion. One can do recursion in FORTRAN, albeit painfully. Is it any surprise that FORTRAN programmers rarely find a need for recursion? The same holds true of command languages as well -- if a particular approach cannot be implemented readily in a command language, then it won't be used. It does seem to me that command languages (shell languages) are an area that needs more work. Perhaps some one is doing this work, but I haven't seen it. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
schwartz@gondor.cs.psu.edu (Scott E. Schwartz) (12/09/87)
In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >In article <3161@psuvax1.psu.edu> schwartz@gondor.psu.edu (Scott E. Schwartz) writes: >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. Agreed, to some extent. But the dark underside of the primos command processor is that you can't ever have more functionality than it gives you at the moment. Unix pipes and such mean that the shell's metacharacters can be aimed at handling the simple general case, and letting shell control structures do the rest. >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.] Well, for the bourne shell this will do: (cd ./old; ls | while read f; do if [ -f $f ] ; then echo $f; fi; done) | while read f; do diff ./old/$f $f >$f.+cmpf; done byzantine, I agree, but easy to whip up. If i've missed a condition that the primos command applies, I be it can be corrected with little difficulty. By the way, how does primos handle something like ls [!B]*.[!c] i.e. multiple internal negation. -- Scott Schwartz schwartz@gondor.cs.psu.edu
chris@mimsy.UUCP (Chris Torek) (12/09/87)
In article <9679@mimsy.UUCP> I wrote: > j=`echo $i | sed 's,.*,,'` Oops, I dropped a character. That should be ... sed 's,.*/,,'` -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jack@cwi.nl (Jack Jansen) (12/09/87)
In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: > [Discussing primos wildcards versus unix wildcards] >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.] Uhm, yes, unfortunately I find the 'feature' quite unusable. I *never* come up with the correct sequence of == and @@, so I have to type the command three times before I get it right. (really retype, that is. 'History mechanism' is something primos has never heard about). I definitely prefer for i in *.[ch]; do diff old/$i $i >$i.diff done (and you can add an 'if [ -d $i ]' if you really care about directories ending in .c or .h. I don't, because I don't *have* directories ending in .c or .h). And, to continue some gripes on primos wildcards: - I would expect them to work *always*. I.e. if I do TYPE @@ (TYPE is primos echo) I would expect a list of all files, *not* '@@'. - If I want all arguments on one line, and I use [WILD @@.TMP], and the result doesn't fit in 80 characters, I DO DEFINITELY NOT WANT IT TO TRUNCATE IT AT EIGHTY CHARS! I lost an important file that way: it was trying to generate a list containing PRECIOUSFILE.TMP, but, unfortunately, the .TMP started at position 81. So, it removed PRECIOUSFILE in stead. sigh. Sorry, there are some neat ideas in primos, but the command processor and it's wildcards is definitely *not* one of them. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (12/10/87)
In article <5565@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > 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. OK: for i in *.[ch]; do > if [ -f $i ] ; then > cmp $i old/$i > $i.cmpf > fi > done Note, the above construct has, potentially, far more power than you needed. Now, if you wish to argue that it's not a "command-line" interface, I would agree. And my response would be, in that case, that one of that complexity/ power is unncessary when you can have real programming interfaces. Incidentally, you *can* put it on a single line... > After several years of using primos, it is clear to me the unix way of > handling wildcards is much less powerfull. Depends how you delimit "wildcards". I think I disagree. > It is clear to me that power, ease of use, etc. have almost no > relation to how operating systems are chosen anyway. Chosen by whom? If marketing was all it took, we'd all be running you-know-what. --keith
blarson@skat.usc.edu (Bob Larson) (12/10/87)
In article <3167@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott E. Schwartz) writes: >In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >>In article <3161@psuvax1.psu.edu> schwartz@gondor.psu.edu (Scott E. Schwartz) writes: >Agreed, to some extent. But the dark underside of the primos command >processor is that you can't ever have more functionality than it gives >you at the moment. Not true, since it allows access to functions that may be user written, and is a programming language in itself. [example in answer to my question ommited. The shortest one I received via mail. (It took advantage of a feature of diff that the others didn't.) >By the way, how does primos handle something like > ls [!B]*.[!c] >i.e. multiple internal negation. Primos does not dirrectly support double negation, however it also has CPL (equivelent to shell scripts): &do i &list [wild ^@@.c] &if [substr %i% 1 1] ^= B &then type %i% &end Substite dir for type if you want to add options. If anyone cares to notice this doesn't handle large directories, I would note that unix lacks (to my knolage) any reasonable way to handle large wildcard expantion, and that fixing the above cpl take 1 more line. I don't plan on continuing the command processor debate, like editors, it is mainly a matter of personal preference. I think primos handles the common case of name generation nicely (without any ambiguities such as those mentioned about an unspecified os in a different message), but lacks direct support for multiple negation. (A rare case for me.) (Where the primos command processor realy looses is in lack of general-purpouse redirection, pipes, and easy handling of multi-tasking.) -- 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
zap@draken.nada.kth.se (Svante Lindahl) (12/10/87)
In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: #For example, how would you do the equivelent of this in unix: # #cmpf *>old>@@.(c,h) == -report ==.+cmpf -file I can do it using either /bin/sh or csh, but it does require more typing than in Primos. The test for existence of the file is not necessary so these examples could be simplified at the expense of risking a few error messages to the terminal. C-shell: % foreach i (`cd old; ls *.[ch]`) > if (-r $i) diff -c old $i > $i.cmpf > end Bourne-shell: $ for i in `cd old; ls *.[ch]` ; do > if [ -r $i ] ; then diff -c old $i > $i.cmpf ; fi > done Svante Lindahl zap@nada.kth.se uunet!nada.kth.se!zap
ignatz@chinet.UUCP (Dave Ihnat) (12/11/87)
This is a little annoying. First, I doubt the PR1MOS CLI can handle
general wildcards in as flexible a manner as sh or ksh; you can truly
construct some bizarre patterns, if you wish. But the second part of
my annoyance is that you *don't* want an expression that rivals the
sendmail syntax for complexity and illegibility; the example given
does, and I know I could come up with some that are worse for the
shell using wildcards, negation, and alternates. Finally, the keynote
is that this is another religious argument, akin to the question
"My {OS | editor | machine } is better than *, because..."
Nobody is ever going to either definitively answer the argument, nor
are we going to convince somebody that X really *is* better than Y,
and sell their box that runs Y to buy an X box.
If a discussion of what should *be put into* a CLI--what features
should be cross-implemented--should spring up, fine. But "my CLI's
better than your CLI" is boring; I've heard it all before over vi vs.
emacs, BSD vs SysX, etc.
--
Dave Ihnat
ihnp4!homebru!ignatz || ihnp4!chinet!ignatz
(w) (312) 882-4673peter@sugar.UUCP (Peter da Silva) (12/14/87)
In article <5565@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > 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.] for i in old/*.[hc]; do diff -c $i `basename $i` > `basename $i`.diff; done Explanation: compare all files in the old subdirectory anding 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 .diff appended. This doesn't filter out directories because I wouldn't bother... but if you want: for i in old/*.[hc]; do if [ ! -d $i ]; then diff -c $i `basename $i` > `basename $i`.diff; fi; done If you want to do it recursively on all subdirectories of 'old': find old -name '*.[hc]' -type f -exec diff -c '{}' '`basename {} `'... These examples, by the way, both use the Primos meaning of wildcards. I presume that's what you want. i.e.: using the 'for i in pat' structure you can perform Primos style wildcarding on UNIX, but not vice-versa. What sort of control structures does Primos support? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
blarson@skat.usc.edu (Bob Larson) (12/16/87)
In article <142@piring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >Uhm, yes, unfortunately I find the 'feature' quite unusable. >I *never* come up with the correct sequence of == and @@, so I have to type >the command three times before I get it right. (really retype, that is. As with most user interface questions, it is a matter of personal preference and what you are used to. >'History mechanism' is something primos has never heard about). There are at least two command line editors for primos 19.4 and later on the market, two I know of being passed around, and one included with primos 21.0 that works with prior version of primos. (The best of the lot in my opinion - I like emacs.) The only os I know of that has such a wide variety is unix -- but with unix you have to replace your whole shell to switch command line editors. >I definitely prefer >for i in *.[ch]; do > diff old/$i $i >$i.diff >done I never had time to dig to deep into my unix manuals for this. It doen't look any more intuitive to me than the primos example. >And, to continue some gripes on primos wildcards: >- I would expect them to work *always*. I.e. if I do > TYPE @@ > (TYPE is primos echo) I would expect a list of all files, *not* '@@'. Well, fix your expectations. Wildcards should only be expaned where filenames are expected. >- If I want all arguments on one line, and I use [WILD @@.TMP], and the > result doesn't fit in 80 characters, I DO DEFINITELY NOT WANT IT TO TRUNCATE > IT AT EIGHTY CHARS! I lost an important file that way: it was trying A. No standard primos command expects a list of files like this. B. The only limit I know of is 160 characters not 80: it applies to commands directly typed to the command processor (not as a result of function calls like wild) and the commands that get their command line from the ancient rdtk$$ call -- anything writen since 19.4 has no reason to use this and many good reasons not to that I won't list here. (Prime is gradually changing over on their utilites.) C. There is a limit of 1024 characters for command lines after function expantion. If this limit is exceeded, an error message is generated and the command is not executed. Therfore, I conclude that this problem must have been a programmer error: using rdtk$$ to read a command line that should be expected to be long. 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
arnold@emory.uucp (Arnold D. Robbins {EUCC}) (12/22/87)
In article <5754@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >>'History mechanism' is something primos has never heard about). > >There are at least two command line editors for primos 19.4 and later >on the market, two I know of being passed around, and one included >with primos 21.0 that works with prior version of primos. (The best >of the lot in my opinion - I like emacs.) The only os I know of that >has such a wide variety is unix -- but with unix you have to replace >your whole shell to switch command line editors. Interestling enough, this is not necessarily so. In the 8th Edition shell, the shell itself has no builtin history mechanism. Instead, if HISTORY is a defined parameter (shell variable), the shell appends the text of each command to the file indicated by $HISTORY. There is a separate command (named '=' and '==') that does command history editing and then submits the new command for execution. By extension, anyone could write their own history editor that worked the same way, without building it into the shell. After considerable thought, this approach, in my opinion, seems both simple and elegant. Too bad we mere mortals can't get v8 or v9. -- Arnold Robbins ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory UUCP: { decvax, gatech, }!emory!arnold DOMAIN: arnold@emory.edu (soon) ``csh: just say NO!''
peter@sugar.UUCP (Peter da Silva) (12/22/87)
In article <5754@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > In article <142@piring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: > >I definitely prefer > >for i in *.[ch]; do > > diff old/$i $i >$i.diff > >done > I never had time to dig to deep into my unix manuals for this. It > doen't look any more intuitive to me than the primos example. The fact that half a dozen people so far have come up with this command line should tell you something. Here's how it works: for each file, i, that matches "*.[ch]" diff the copy of that file in "old" with the copy in the current directory, putting the output in a file of the same name but with a suffix of ".diff" appended. Which is what your example does... but less explicitly. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.