Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!mit-eddie!genrad!decvax!decwrl!hplabs!felix!scgvaxd!stb!michael
From: michael@stb.UUCP (Michael)
Newsgroups: comp.sys.amiga
Subject: Re: Pattern Matching & documentation
Message-ID: <825@stb.UUCP>
Date: Sun, 28-Dec-86 17:15:31 EST
Article-I.D.: stb.825
Posted: Sun Dec 28 17:15:31 1986
Date-Received: Tue, 30-Dec-86 21:38:16 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <1908@jade.BERKELEY.EDU>
Organization: STB BBS, Los Angeles, CA
Lines: 114
Summary: ...

In article <1908@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes:
> 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?
> 

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.

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

Very simple.
	set noglob
	foreach i ($*)
		echo $i
	end

That does it, no?

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

[comments about the ease of having the shell do it vs. the desire for
odd programs to do it their own way]

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

where there exists a file called existensialistic_programming_fun

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