Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Newsgroups: comp.sys.amiga
Subject: Re: Pattern Matching & documentation
Message-ID: <1908@jade.BERKELEY.EDU>
Date: Thu, 11-Dec-86 21:43:02 EST
Article-I.D.: jade.1908
Posted: Thu Dec 11 21:43:02 1986
Date-Received: Sun, 14-Dec-86 19:24:13 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU> <3313@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: 78

In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes:
>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?

If it's ok for finger to do it's own pattern matching, why isn't it ok
for list, dir, etc. to do their own pattern matching?

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

Consider a shell script:

	for i in $*
	do
		echo $i
	done

which acts like echo, but puts each word on a seperate line. Now, try
convincing it to echo a "*". Notice that your quoting mechanisms don't
work right.

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

How many of the rest of them use file names? Does it make sense for
them to do pattern matching if they aren't dealing with file names?
And you're right, list is brain-damaged.

>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.

Not clear that shell file name expansion should handle assigned names,
as they are not part of the file system. On the other hand, if you're
doing pattern matching, then it doesn't matter that they're not part
of the file systems. Those commands that need to deal with them can.

>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.

Sorry, but as a user, I want the pattern matching to work against the
set of objects with the same type as the argument. I don't really care
who does it either, but it's going to require some work on the part of
the programmer NO MATTER HOW YOU 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.

I'd like to have it done for me, too. But I'd much rather be able to
do it right than have the CLI impose an arbitrary mechanism on me.

>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)

Gee, I didn't have any problem with it. But I'd much rather have something
that looked like

	type  outfile=filename

with abbrevs (Dillon's shell does abbrevs, at least for built-in
command names. Nice going, Matt). That's kind of redundant with shell
redirection. Nice for users who don't like the cryptic "type >filename
", though.  Of course, if the shell is doing file
name expansion, then you loose the ability to grab the output name by
pattern.

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

Look at the subject line: it says "Pattern matching", *NOT* file
expansion. That's the point - not every command deals with files, and
having your command processor act like they do is a crock. Wouldn't it
be nice if you could use the exact same regular expressions for
commands that dealt with processes (or font names) as you do for
commands that deal with files? WITHOUT having to quote them. Or do you
find consistency a problem?