Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!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: <2073@jade.BERKELEY.EDU>
Date: Thu, 1-Jan-87 03:32:37 EST
Article-I.D.: jade.2073
Posted: Thu Jan  1 03:32:37 1987
Date-Received: Thu, 1-Jan-87 19:05:06 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <1908@jade.BERKELEY.EDU> <825@stb.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Organization: Missionaria Phonibalonica
Lines: 171

In article <825@stb.UUCP> michael@stb.UUCP (Michael) writes:
>One moment. If you are talking about a program that is designed to work with
>something that the CLI cannot possibly see, then the command can pattern match.
>
>If you are working with something that the CLI can see, then the CLI should
>expand it.

Uh, if a program can see the names, why can't the CLI see them? After
all, it's just a program. More importantly, how is the CLI supposed to
know what it should or shouldn't expand, and what that expansion
should be against?

[Good old shell scripts again!]
>Very simple.
>	set noglob
>	foreach i ($*)
>		echo $i
>	end
>
>That does it, no?

Very nice - much better than the "$@" solutions, as those don't work
on all shells. Of course, in either case you have to depend on the
programmer who wrote the script to do it correctly. Experience tells
me that neither AT&T nor Berkeley will always get it 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.
>
>Here is a quick look at c: and the programs that use files:
>Assign
>AddBuffers
>CD
>Copy	delete	diskchange	echo	ed	edit	execute	fastdir
>filenote	info	install	join	list	makedir	'newcli from'
>path	relable	search	run	sort	type	Z (manx editor)

I disagree - many of them deal with devices, not files. Part of them
aren't standard utilities. Echo doesn't deal with files, just words.
If you delete these things you have left:

assign	CD	delete	ed	edit	execute	filenote	join
list	makedir	newcli	path	search	run	sort	copy	type

In addition, assign, cd, execute, newcli, and run only deal with one
file, and it only makes sense for them to deal with one file. They
should complete, not pattern match. I don't know if ed and edit deal
with multiple files, so I'm going to assume they don't (add two
further on if they do but don't pattern match.) Makedir and filenote
don't accept multiple files, but should.  Sort and type have the
broken from/to semantics. Path, search and join should do pattern
matching, but don't.  List does patterns (brokenly), delete, copy and
search do patterns correctly.

In summary: 7 commands for which multiple arguments don't make sense;
2 for which they do, but don't support them; three with bogus
semantics; three that don't support pattern matching but should, and
three that do things right. Or 10 for which it can be argued that
things are done right, six for which things are done wrong.

You really thing unix does that much better? I suspect that over half
the commands have arguments that don't deal with files, which makes
their command line handling (as far as I'm concerned) wrong.

>> >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.
>> 
>On the contrary, they are part of the file system. AmigaDos recognizes them,
>does it not? Next thing you know, you'll claim nil: is not part of the file
>system. Would you claim that /dev/null is not part of the file system?

It appears that one of the really nice features of Unix has confused
you. You see, /dev/null is TWO things. Firstly, it's part of the Unix
file system; or more accurately, it's in the Unix file system
namespace. It can be any arbitrary file. I can put data in it, take it
back out, grep for things in it, and have it all work; like so -

Script started on Wed Dec 31 23:42:50 1986
eris# file /dev/null
/dev/null:	character special (3/2)
eris# mv /dev/null /dev/save.me
eris# echo hello > /dev/null
eris# cat /dev/null
hello
eris# rm /dev/null
eris# mv /dev/save.me /dev/null
eris# file /dev/null
/dev/null:	character special (3/2)
eris# ^D
script done on Wed Dec 31 23:43:38 1986

On the other hand, the file named /dev/null *BY CONVENTION* points to
a trivial device. The ability to have arbitrary filenames point to
arbitrary devices is a major win for Unix.

AmigaDOS isn't so nice, device names are magic; they aren't files,
they are DEVICES. To see the difference, try listing par:. Or how
about copying df0: to a single file in RAM:? Odd, it won't do it.
Unix does reasonable things for both of these attempts.

So I just made your prediction come true; nil: isn't part of the file
system. It's part of the OS, so of course AmigaDOS recognizes it.
Symbolic names that point to a directory are something else again. A
nice feature (that Unix ought to have, and done better than VMS), but
they confuse the issue.

>> Gee, I didn't have any problem with it. But I'd much rather have something
>> that looked like
>> 
>> 	type  outfile=filename
>> 
>> Of course, if the shell is doing file
>> name expansion, then you loose the ability to grab the output name by
>> pattern.
>
>Oh yea? What about
>cat *.c > exist*

Sorry, but "> exists*" is NOT "outfile=filename". One is short and
cryptic, the other nice and readable. Done right, you'd input "o=fi*"
(or something similar) in the second case, but could write it out
longhand for scripts (where readability can be important).

[A description of pattern matching versus filename expansion]
>OK, Now I understand what you are driving at. But here is one major question
>for you:
>
>How will you do it?
>At some point, you have to have a routine that takes ARGV, ARGC, and a list
>for pattern matching. How are you going to do it so that it can easily
>do file, font, library, device, message ports, active tasks, etc, etc, etc.

Well, there are a couple of ways. One would be to provide a single
subroutine that took three arguments: argv, argc and a description of
what the arguments should look like (that last may take more than one
argument; possibly varargs code needs to be used). It could either
twiddle argc and argv (which would violate the ANSI standard) or you
could call it multiple times (try "man 3 getopt" to see what I mean).
Other library combinations are possible.

However, I've decided that the shell should do it, based on command
description files. The main reason for this is that it gives the user
LOTS of power in tailoring the interface. I've just realized that you
could still do it in a library and give the user that power. On Unix,
the result would (almost certainly) be an ugly hook to find the
correct description file. AmigaDOS might work better though. Have to
go think about it.

>For anything based on an exec node list, its not hard. But not everything is.

Not much harder than doing file expansion. The hard part in every case
is getting a list of all the objects in the "universe." And any of the
above approaches means that it only has to be done once (barring
reinventing the wheel).

The shell description I've mentioned that talks about all this (among
other things) has been written. I realized that it would be suitable
for publication in SIGSmall/SIGPC, and wrote it for that. I'm going to
be uploading the result in the next day or two, and will post a draft
here.