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: <2104@jade.BERKELEY.EDU>
Date: Wed, 7-Jan-87 02:48:14 EST
Article-I.D.: jade.2104
Posted: Wed Jan  7 02:48:14 1987
Date-Received: Wed, 7-Jan-87 18:44:07 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer)
Organization: Missionaria Phonibalonica
Lines: 145

In article <3549@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes:
>> = Mike Myers

Uh, since I'm Mike Meyer (not plural, and add an e), and I said these
things, I think I'll correct the attribution.

>>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?
>
>Very simple: it doesn't, and can't. However, files should be matched
>against files, fonts against fonts, etc. But, the CLI can't tell what
>it is, or can it? It can guess, i.e.

It can if it's told what they are. See the article I posted a couple
of days ago that's a draft of "A Shell for Modern Personal Computers,"
which describes one way of doing just that.

>A. Different people would want different orders in type-list
>B. Different people would want different things in type-list
>C. Some things may be hard to put into type-list

The above paper does it a different way, which avoids these problems.

>>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.
>
>I agree, and Microsoft and SCO aren't much better.

MicroShaft and SCO are selling AT&T software (either V or III,
nowadays. I don't think anyone is still selling v7), so chances are
you are seeing AT&T bugs. My experiences with MicroShaft are such that
I'd expect them to introduce a whole new set of bugs without fixing
any of the old ones. [End obligatory large software vendor bashing.]

>Here we have some disagrements. I feel that ANY time a program deals
>with files, it should be expanded, even if it is only one file
>(like CD). As for non-standard, thats only Z and fastdir.
>Besides, echo does deal with filenames--on Unix, I use it as a fast
>ls to see if a file exists.

I've used that trick before, but that's a kludge. Ls is nicer, and
nearly as fast on well-run systems.

With only ONE argument, I'd much rather have completion. If you can
get to a 4.3 system, do "set filec", and then try typing escapes in
the middle of file names. If you can't do that, get a copy of
microGNUEmacs, and play with typing spaces at prompts for buffer and
command names.

>3 with bogus semantics. Thats one STRONG reason for this stuff to
>be in a common subroutine library or by the shell.

It's even better to put it where the user can play with it. See the
above-mentioned posting.

>>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.
>
>Hmm.. I can't think of a command for which the file-name expansion
>hurts me. Mail and history are a different problem (bang bang)

Almost every time I use sed, I have to go out of my way to quote the
arguments. Without filename expansion, this wouldn't be a problem.
Other expansion tricks hurt other programs. Of course, you probably do
what I do, and make sure things never have the magic characters in
them. We have odd restrictions on the names in our CMS system because
of oddities in the Unix shell!

>>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.
>
>Well, lets see. I can mount arbitrary device handlers with arbitrary
>Dos device names, but I can't unmount. So, the only restrictions are that
>I can't avoid the colon at the end, and I can't change a name once
>gdven.

Huh? You mean you can create a device gort/foo: ??? How about
gort/my_foo:, then do a "list gort" to see the devices in it. I think
not, but could be wrong (never had a reason to do anything THAT
bizarre).

>As for copying df0: to ram:, or TYPE DF0: TO DF1:, or something:
>I belive this is a fault of the BCPL programs doing checks that they
>shouldn't be checking. If I am wrong,
>
>*** BUG REPORT ***

I don't think it's a bug report - I think it's confusion on your part.
Have you ever worked with a large system which had similar features
(TOPS-10, VMS, and probably others)? On those systems, devices (and
system logicals) ARE NOT part of the file name space. Then again, they
tend to have ugly three-part file names: device, followed by a magic
character; a directory path, with magic characters at both ends, and
finally a file name. Probably split into a name and an extension, with
a magic character seperating. Compared to such kludgyness, AmigaDOS is
nice

Of course, you still have to deal with the problem of "list par:"
saying "packet request type unknown". Or is that a bug, also?

>Actually, I think they should be FULLY integrated, and if they aren't,
>blame Dos; if they are, blame the BCPL programs.

I tend to think they aren't fully integrated, and think that DOS
should be blamed. But it's hard to blame the designers: they did that
work before Unix really became popular, and the way they did it was
the way almost everyone else was doing it back then. "Blame it on
TRIPOS."

>I don't know about you, but I HATE outfile=x type things. Absolutely HATE.
>DO NOT put that into amiga dos. Religious fight up ahead 8<)
>
>Besides, quoting > is easy: \> or '>'. Quoting 'outfile=file*' is not
>as easy, and you have to get it to expand and then ignore the outfile= part.

You don't have to quote it if the command is doing the expanding
instead of the shell. You seem to have ignored the possibility of it
being shortend to o=fi*, also. And o= isn't noticable harder to type
than > (to key presses, either way, on the Amiga keyboard).

Of course, the shell can do all of this for you. See the
afore-mentioned posting for details.

>Well, we both agree that the shell should do it. We both agree that
>it should be user configurable. Soon, we'll have something we both
>hate equally--that will be it.

Yes, but we got to the shell doing it via totally different paths. You
started wanting a dumb shell, ala Unix, that just expands everything.
I started wanting more intelligent handling of arguments. Making that
user-configurable pushes things from the command to the command
processor.  See the much-mentioned paper to see where that leads you,
and how FAR that is from a dumb "file-expand-every-argument" shell.

If that posting hasn't gotten to you by the time you see this,
something probably broke. Please let me know.