Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » comp.sys.amiga » Pattern Matching & documentation
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Pattern Matching & documentation [message #293461] Wed, 19 November 1986 00:43 Go to next message
mwm is currently offline  mwm
Messages: 111
Registered: May 2013
Karma: 0
Senior Member
Article-I.D.: jade.1731
Posted: Wed Nov 19 00:43:50 1986
Date-Received: Wed, 19-Nov-86 21:52:46 EST
References: <954@blia.BLI.COM>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Organization: Missionaria Phonibalonica
Lines: 14

In article <954@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes:
 > I would have thought that a generally implemented facility as pattern
 > matching would be described in the introductory sections of the manual
 > instead in the text of the description of a specific command.

Nope. Pattern matching is implemented on a per-command basis, not by
the cli. Thus, commands may or may not pattern match, or may only
pattern match for certain arguments. This is a win. It's not clear
that AmigaDOS has the best solution, but at least it's a start.

For those who don't think per-argument pattern matching is a win,
consider "finger *" and "finger *@*.berkeley.edu". 

	  

		
		
		
Re: Pattern Matching & documentation [message #293690 is a reply to message #293461] Mon, 01 December 1986 15:25 Go to previous messageGo to next message
cc1 is currently offline  cc1
Messages: 10
Registered: May 2013
Karma: 0
Junior Member
Article-I.D.: curly.3237
Posted: Mon Dec  1 15:25:10 1986
Date-Received: Tue, 2-Dec-86 21:25:13 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU>
Reply-To: ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten)
Organization: Ucla Computer Club (disclaimer)
Lines: 19

 > For those who don't think per-argument pattern matching is a win,
 > consider "finger *" and "finger *@*.berkeley.edu". 

Ok. Whats wrong with finger \*@\*.berkeley.edu or
finger "*@*.berkeley.edu" or
set noglob
finger *@*.berkeley.edu
unset noglob
?
Pattern matching on all commands is better as then every command has it
by default. Try doing a join on the result of running disksalv. Try doing
a usercommand *. Try doing a, well, you get the idea. Only the supplied
BCPL commands assume that they only have one file name, and that because
the supplied CLI won't expand wildcards. I've asked C-A to put multiple
filename support in, but I don't think they will.

			Michael Gersten
      Views expressed here may not be those of the Computer Club, UCLA, or
  anyone in their left OR right mind.  And that's the name o' that tune.
Re: Pattern Matching & documentation [message #293706 is a reply to message #293461] Tue, 02 December 1986 20:33 Go to previous messageGo to next message
mwm is currently offline  mwm
Messages: 111
Registered: May 2013
Karma: 0
Senior Member
Article-I.D.: jade.1805
Posted: Tue Dec  2 20:33:51 1986
Date-Received: Wed, 3-Dec-86 09:22:35 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Organization: Missionaria Phonibalonica
Lines: 47

In article <3237@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes:
 >> For those who don't think per-argument pattern matching is a win,
 >> consider "finger *" and "finger *@*.berkeley.edu". 
 > 
 > Ok. Whats wrong with finger \*@\*.berkeley.edu or
 > finger "*@*.berkeley.edu" or
 > set noglob
 > finger *@*.berkeley.edu
 > unset noglob
 > ?

Because none of those do what the command ought to do - run a finger
on all the *users* in the apropriate domain. All you've done is turned
off the pattern matching, not made it work reasonably well. Worse yet,
part of your turning of methods won't work if finger happens to be a
shell script. Since it's not uncommon to have shell scripts that
invoke other shell scripts, this can get to be a major pain in the
ass. Why should I have to know how many levels of shell script are
involved in a command when I run it?

 > Pattern matching on all commands is better as then every command has it
 > by default. Try doing a join on the result of running disksalv. Try doing
 > a usercommand *. Try doing a, well, you get the idea. Only the supplied
 > BCPL commands assume that they only have one file name, and that because
 > the supplied CLI won't expand wildcards. I've asked C-A to put multiple
 > filename support in, but I don't think they will.

I certainly hope not. It would be better if they fixed the library
mechanism (the linkers, maybe?) so you could invoke routines in shared
libraries without doing an explicit "openlibrary", then providing the
pattern-matching code in a library. They should also provide hooks so
you can pattern-match against things other than file names.  Then the
"user interface design philosophy" should encourage people to expand
filenames against the file system, device names against devices (hmm -
never tried that. It may work.), font names against fonts, command
names againts file in PATH, process names/id's against etc.  All of
which niceness is impossible/painfull if the shell is expanding names
for you.

Oh, yeah - many of the supplied BCPL commands work quite well with
patterns and multiple file names. I run things against #? quite a bit
(search, delete, copy being the most notable ones).  Also, there are
quite a few PD C programs that only swallow one argument. In any case
do you (as a user) really care if the command or the shell does it? If
so, why?

	  

		
		
		
Re: Pattern Matching & documentation [message #293769 is a reply to message #293461] Wed, 03 December 1986 19:48 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: mark@ece-csc.UUCP (Mark Lanzo)
Article-I.D.: ece-csc.3135
Posted: Wed Dec  3 19:48:15 1986
Date-Received: Fri, 5-Dec-86 10:37:42 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU>
Reply-To: mark@ece-csc.UUCP (Mark Lanzo)
Organization: The loony bin
Lines: 47

to quote pieces from a couple of previous postings:

 > For those who don't think per-argument pattern matching is a win,
 > consider "finger *" and "finger *@*.berkeley.edu". 

and 

 > Ok. Whats wrong with finger \*@\*.berkeley.edu or
 > finger "*@*.berkeley.edu" or
 > set noglob
 > finger *@*.berkeley.edu
 > unset noglob
 > ?

Well, I agree that the above works, but it sure is a crude way of doing
things.  Also, the filename expansion et al are supposed to be making the
user interface EASIER to work with, and more regular.  Suddenly having to
add escape codes tends to defeat the purpose -- and is particularly 
confusing to neophyte users who don't readily understand these intricacies.
The Amiga folks really ought to work on making the user interface better
and easier to use, not more cryptic.  There are lots of rough spots in the
CLI interface which really should be improved upon; and in 99% of the
cases could be without a great deal of difficulty.  Anyways ...

An idea:  if there are any spare bits in a file's "protection"
code (read/write/execute/delete/archive/whatever...), maybe one could be
defined as a "Filename expansion" bit.

I agree with the crowd wanting the filename expansion to be done automatically
by the system since it would contribute greatly to a uniform user interface
and makes writing application a good deal easier at the same time.
It seems silly to have to include gobs of filename expanding code in every
program I write which can accept a filename as an argument (which is
probably most programs).

Still, it would be nice to be able to disable the filename expansion for 
a few special programs (such as Unix "finger").

So, what if the system by default expanded filenames on the command line
before calling a program, UNLESS some special bit in the file's access
code was set?

Just a thought ....


      -- Mark --
      flames to /dev/null please!
Re: Pattern Matching & documentation [message #293773 is a reply to message #293461] Fri, 05 December 1986 13:06 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: cmcmanis@sun.uucp (Chuck McManis)
Article-I.D.: sun.10176
Posted: Fri Dec  5 13:06:26 1986
Date-Received: Fri, 5-Dec-86 21:15:44 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3135@ece-csc.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 19
Summary: Lattice Library can pattern match


In article <3135@ece-csc.UUCP> Mark Lanzo writes :

*>I agree with the crowd wanting the filename expansion to be done automatically
*>by the system since it would contribute greatly to a uniform user interface
*>and makes writing application a good deal easier at the same time.
*>It seems silly to have to include gobs of filename expanding code in every
*>program I write which can accept a filename as an argument (which is
*>probably most programs).

The 3.1 version of the lattice compiler has a library routine to do filename
expansion/pattern matching in either AmigaDOS mode (#? etc) or MS-DOS mode
with *.* etc. This at least frees one from having to write gobs of code
but does leave it up to the application to expand it. 

-- 
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
Re: Pattern Matching & documentation [message #293780 is a reply to message #293461] Fri, 05 December 1986 19:11 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: dpz@topaz.RUTGERS.EDU (David P. Zimmerman)
Article-I.D.: topaz.7527
Posted: Fri Dec  5 19:11:49 1986
Date-Received: Fri, 5-Dec-86 22:48:39 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU> <3135@ece-csc.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 31

 >> Ok. Whats wrong with finger \*@\*.berkeley.edu or
 >> finger "*@*.berkeley.edu" or
 >> set noglob
 >> finger *@*.berkeley.edu
 >> unset noglob
 >> ?
 > 
 > Well, I agree that the above works, but it sure is a crude way of doing
 > things.  Also, the filename expansion et al are supposed to be making the
...
 > An idea:  if there are any spare bits in a file's "protection"
 > code (read/write/execute/delete/archive/whatever...), maybe one could be
 > defined as a "Filename expansion" bit.

That's an interesting hack, but a hack nonetheless.  Lord knows we
have enough problems with AmigaDOS without having to introduce hacks
into it - leave the file status bits for the status of the file.

Of course, now I've got to give my own idea.  Make a system call that
given a wildcard will return the appropriate expansion.  You still
have ease of wildcarding for the programmer, and yet also have
consistency for the user.  No hacks, no muss, no fuss, and a lot less
work for the OS, which only has to do expansion when asked to.


					-dpz-
-- 
David P. Zimmerman	"When I'm having fun, the world doesn't exist."

Arpa: dpz@rutgers.rutgers.edu
Uucp: ...{harvard | seismo | pyramid}!rutgers!dpz
Re: Pattern Matching & documentation [message #293837 is a reply to message #293461] Sat, 06 December 1986 01:00 Go to previous messageGo to next message
james is currently offline  james
Messages: 26
Registered: May 2013
Karma: 0
Junior Member
Article-I.D.: uw-atm.70
Posted: Sat Dec  6 01:00:55 1986
Date-Received: Sun, 7-Dec-86 22:21:52 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3135@ece-csc.UUCP>
Organization: Dept. of Atmospheric Sciences, U. of Washington
Lines: 21
Summary: Right on! Wildcard expansion by default, but not forced on you.

In article <3135@ece-csc.UUCP>, mark@ece-csc.UUCP (Mark Lanzo) writes:
 >  An idea:  if there are any spare bits in a file's "protection"
 >  code (read/write/execute/delete/archive/whatever...), maybe one could be
 >  defined as a "Filename expansion" bit.
 >  ...
 >  So, what if the system by default expanded filenames on the command line
 >  before calling a program, UNLESS some special bit in the file's access
 >  code was set?

   Thats EXACTLY the way it should be done.  I use the Primos OS which does
things this way.  So, if you write a 'normal' program and don't do anything
special, the command processor automatically handles wild card expansion
(and many other features).

   The bits can either be in the executable format, or in the file header,
as long as there is a standard.
-- 
---------------------------------------------------------------------------
James M Synge @ Dept. of Atmos Sci, U of Washington (@ DEC in NH, January)
VOX: 1 206 543 0308 (W)   UUCP: uw-beaver!geops!uw-atm!james
     1 206 455 2025 (H)   ARPA: geops!uw-atm!james@beaver.cs.washington.edu
Re: Pattern Matching & documentation [message #293885 is a reply to message #293461] Tue, 09 December 1986 02:12 Go to previous messageGo to next message
mwm is currently offline  mwm
Messages: 111
Registered: May 2013
Karma: 0
Senior Member
Article-I.D.: jade.1860
Posted: Tue Dec  9 02:12:44 1986
Date-Received: Tue, 9-Dec-86 11:16:59 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU> <3135@ece-csc.UUCP> <7527@topaz.RUTGERS.EDU>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Organization: Missionaria Phonibalonica
Lines: 29

In article <7527@topaz.RUTGERS.EDU> dpz@topaz.RUTGERS.EDU (David P. Zimmerman) writes:
 >> An idea:  if there are any spare bits in a file's "protection"
 >> code (read/write/execute/delete/archive/whatever...), maybe one could be
 >> defined as a "Filename expansion" bit.
 > 
 > That's an interesting hack, but a hack nonetheless.  Lord knows we
 > have enough problems with AmigaDOS without having to introduce hacks
 > into it - leave the file status bits for the status of the file.

We looked at doing something like that for Unix. It'd work better for
AmigaDOS (since nothing uses the rwx bits yets), but it still suffers
from wanting to glob against things other than files.

 > Of course, now I've got to give my own idea.  Make a system call that
 > given a wildcard will return the appropriate expansion.  You still
 > have ease of wildcarding for the programmer, and yet also have
 > consistency for the user.  No hacks, no muss, no fuss, and a lot less
 > work for the OS, which only has to do expansion when asked to.

Right idea, but not quite done right. The routine belongs in a shared
library, not in the OS (with the note that AmigaDOS/C doesn't handle
shared libraries well, of course!). Cramming everything into the OS
produces things like 4BSD: bloated (Berkeleyphiles don't get upset;
V the system isn't any better.)

So how about it? Matt, want to convert your.lib into a shared library,
and put the regexp code into it? I can even provide PD regexp code.

	  

		
		
		
Re: Pattern Matching & documentation [message #293898 is a reply to message #293461] Tue, 09 December 1986 12:24 Go to previous messageGo to next message
dillon is currently offline  dillon
Messages: 81
Registered: November 1985
Karma: 0
Member
Article-I.D.: cory.8612091724.AA05017
Posted: Tue Dec  9 12:24:01 1986
Date-Received: Wed, 10-Dec-86 03:56:27 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 13


	Two problems with making MYLIB it a dynamic library:

	(1) Currently, a library form of MY.LIB would be too unstable in
	    that people using new programs with old libraries will tend to
	    crash their machines rather than get linker errors

	(2) The library is never complete...  I keep adding things to it.

	(3) Not everybody will have the library.  I want to be able to
	    post uuencoded executables that work for everybody.

				-Matt
Re: Pattern Matching & documentation [message #293929 is a reply to message #293461] Fri, 05 December 1986 19:58 Go to previous messageGo to next message
cc1 is currently offline  cc1
Messages: 10
Registered: May 2013
Karma: 0
Junior Member
Article-I.D.: curly.3313
Posted: Fri Dec  5 19:58:23 1986
Date-Received: Sat, 13-Dec-86 21:48:27 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU>
Organization: Ucla Computer Club (disclaimer)
Lines: 58
In-Reply-To: <1805@jade.BERKELEY.EDU>


In article <1805@jade.BERKELEY.EDU> you write:
 > In article <3237@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes:
 >>> For those who don't think per-argument pattern matching is a win,
 >>> consider "finger *" and "finger *@*.berkeley.edu". 
 >> 
 >> Ok. Whats wrong with finger \*@\*.berkeley.edu or
 >> finger "*@*.berkeley.edu" or
 >> set noglob
 >> finger *@*.berkeley.edu
 >> unset noglob
 >> ?
 > 
 > Because none of those do what the command ought to do - run a finger
 > on all the *users* in the apropriate domain. All you've done is turned
 > off the pattern matching, not made it work reasonably well. Worse yet,
 > part of your turning of methods won't work if finger happens to be a
 > shell script. Since it's not uncommon to have shell scripts that
 > invoke other shell scripts, this can get to be a major pain in the
 > ass. Why should I have to know how many levels of shell script are
 > involved in a command when I run it?

What I did was just what you did--namely, pass a *@* to the finger
program. If it doesn't know how to handle this, is that my fault?

As for shell scripts, I'm not sure I understand the question/complaint.

[my comments about the benefit of pattern matching, and using join as
an example]

 > I certainly hope not. It would be better if they fixed the library
 > mechanism (the linkers, maybe?) so you could invoke routines in shared
 > libraries without doing an explicit "openlibrary", then providing the
...
 > Oh, yeah - many of the supplied BCPL commands work quite well with

ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED
form of matching that can only check the current directory.

I feel that the CLI should properly handle *:file (ops, #?:file) things.
In fact, I tried doing a DIR #?:, and got a requester for a disk.

So, the problem isn't that it should be done, the question is who
should do it. As a user, I don't care AS LONG AS ALL COMMANDS DO IT.
As a programmer I prefer to have it done for me. As a pesimistic
observer, I note that many people won't do it unless it is as simple
as 'PatternMatch (argc, argv)'; even then, some still won't.

Finally, I *HATE* programs that assume that their first filename is
for input, and the second one is output. TYPE is that way. I lost
several files that way (do NOT say read the manual; I did, and that
was NOT clearly pointed out)

Lastly, what do font names/process names have to do with file expansion?

			Michael Gersten

      Views expressed here may not be those of the Computer Club, UCLA, or
  anyone in their left OR right mind.  And that's the name o' that tune.
Re: Pattern Matching & documentation [message #293936 is a reply to message #293461] Thu, 11 December 1986 19:21 Go to previous message
Anonymous
Karma:
Originally posted by: mic@ut-ngp.UUCP (Mic Kaczmarczik)
Article-I.D.: ut-ngp.4421
Posted: Thu Dec 11 19:21:10 1986
Date-Received: Sat, 13-Dec-86 22:44:53 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU>
Reply-To: mic@ngp.UUCP (Mic Kaczmarczik)
Organization: UTexas Computation Center, Austin, Texas
Lines: 37
Summary: TOPS-20 COMND JSYS, anyone?

has a description of it's arguments hidden in
 > a file somewhere, and the command processor (DCL) checks that. Prompts
 > for missing arguments, globbing against apropriate universes,
 > type-checking on arguments; ALL provided by DCL! Carried to extremes,
 > you even get auto-completion on arguments.
 > 
 > Anyone want to do a DCL-like shell for AmigaDOS? :-)
 > 
 > 	

How about a TOPS-20 EXEC-like shell, with filename expansion, instant
help text, and noise words? Although the TOPS-20 approach is similar
to VMS, TOPS-20 programs invoke a subroutine library to parse command
lines an item at a time.  DCL uses a table (stored as an executable
image, hint, hint) to parse the command line before the program is
even loaded, so the program has no chance to intervene during command
parsing.  Of course, the programmer has to do even *more* work, so I
suppose I could live with table-driven parsing, as long as I could use
question mark and command completion :-)

There is code in Amiga Kermit to do this sort of thing already, but it
would need some work to put it into a shell.  If anybody writes a
shell like this, PLEASE put as much of the code as you can into
reentrant *libraries*, so you don't pay as large a penalty for having
more than one shell loaded!  That's the reason I'm sticking with the
CLI; I just can't see spending 20-40K worth of memory on my poor
little 512K system just to run another copy of a shell...

--mic--
Re: Pattern Matching & documentatio [message #293945 is a reply to message #293461] Tue, 09 December 1986 16:36 Go to previous message
hamilton is currently offline  hamilton
Messages: 57
Registered: May 2013
Karma: 0
Member
Article-I.D.: uiucuxc.172200011
Posted: Tue Dec  9 16:36:00 1986
Date-Received: Sun, 14-Dec-86 01:04:24 EST
References: <7527@topaz.RUTGERS.EDU>
Lines: 18
Nf-ID: #R:topaz.RUTGERS.EDU:7527:uiucuxc:172200011:000:841
Nf-From: uiucuxc.cso.uiuc.edu!hamilton    Dec  9 15:36:00 1986


dpz@topaz says:
 >  Of course, now I've got to give my own idea.  Make a system call that
 >  given a wildcard will return the appropriate expansion.  You still
 >  have ease of wildcarding for the programmer, and yet also have
 >  consistency for the user.  No hacks, no muss, no fuss, and a lot less
 >  work for the OS, which only has to do expansion when asked to.

    it doesn't have to be a system call; a library routine (either kind)
will suffice.  take it one step further, and have 2 versions of your
c compiler startup code (?startup.o or c.o or whatever).

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703
CIS:    [73047,544]			PLink: w hamilton
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Educational discounts (was Re: The trouble with the Amiga)
Next Topic: December meeting of BADGE
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 16:10:36 EDT 2024

Total time taken to generate the page: 0.05091 seconds