Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!cernvax!chx400!ethz!zeller
From: zeller@ethz.UUCP (Lukas Zeller)
Newsgroups: comp.sys.mac
Subject: Re: System 7.0 concern & wish list (LONG)
Keywords: System 7.0, Finder, filenames
Message-ID: <2244@ethz.UUCP>
Date: 15 Oct 89 01:40:54 GMT
References: <8821@spool.cs.wisc.edu> <700@pai.UUCP>
Reply-To: zeller@bernina.ethz.ch.UUCP (Lukas Zeller)
Distribution: comp
Organization: ETH Zuerich, Switzerland
Lines: 74

In article <8821@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes:
> [Some very interesting alternatives to pattern-matching for file names and
>  a vote against including the latter in System 7.0] 

In article <700@pai.UUCP> erc@pai.UUCP (Eric Johnson) replies: 
>[...] I suspect we use 
>our computers for different things.  For example, I often program using 
>the C language.  Most C source files are given a name ending in ".c" and
>most C header files are given a name ending in ".h"--these conventions
>may be right or wrong, but they are all-pervasive.
> [...]
>So, why do I want filename-based searches on the Mac?  Because
>every day on UNIX I use filename-based searches and I find these
>searches invaluable (e.g., grep socket *net*.c ).  Other times
>I want to back up all the source files [...] using *.c, *.h and so on.
I agree with the first part of the sentence above: I'd like to back up
all my source and header files without having to select them one by one, too.
But do we need wildcards for that ? I don't think so. 
When you type "*.c" in UNIX, what you want to say is: "all C source files".
And only because a *property* of the file (the fact that it contains
C source) is encoded in the *name* of the file instead of being kept as a
separate piece of information, you need wildcards to extract it.
In the file system proposed by Anthony Rich the "keyword" list would contain
entries labelled "C source file" or "C header file". Selections could then
be based on a keyword: Option clicking a file would bring up the Info dialog
box with a list of keywords. You would select "C source file" from the list
and hit a "Select files with same keyword" button. Of course, most probably
the details would be different (I'm not a human interface designer) but
the need for wildcards would be eliminated. Even with today's finder it is
obvious how additional properties of the file (location, type, creator and
color) make wildcards more and more useless: Nobody could survive a single
day without wildcards under UNIX, but most Mac users have, since 1984 :-)

>> Trouble is, it has become common practice to "encode" additional
>> information into filenames, like the file's type, its version number,
>> whether it has been compressed, and the like.  It's not unusual to see
>> files with cryptic names like "xmodem17.hqx".  Filenames aren't the right
>> place to store all that information, 
>
>Sorry, but this is common practise.  Right or not, this method is
>used.
(mild flame) If the MAC OS had been built on what was "common practise" then,
you could not distinguish it from MS-DOS today. Is that what you want for
the future ? (mild flame off)

>  One reason may be that listing the names of the files in
>a directory is often the most information you will get about the
>contents of the files.
Exactly. And that's the reason why we need an extended "Info" box, and NOT
a method that encourages encoding additional information into file names.

>  UNIX does have a "file" command that will
>try to guess the type of a file (e.g., executable, ascii text, c program,
>awk script, etc.), but still most people use the file name method.
(mild flame) If this command would not *guess* but *know* about the
file contents without reading the file and then doing some statistics
(many ((((())))) --> LISP, for example :-), and if "find" was
not a separate command but a part of "ls", the "file name method" would
be far less popular. (mild flame off) 

>You have a lot of good arguments, but I feel filename-based searches
>would add a lot to the already-nice Mac interface. Perhaps Apple's
>user interface guidelines could help limit abuse of this feature.
I fear that wildcards would destroy more of the user interface's consistency
than they would add to its functionality. And because consistency is THE
philosophy behind the "user interface guidelines", I doubt if Apple will
include wildcards. Maybe System 7.0 will prove me wrong :-(

==========================  +---------------------------+  *****************
      Lukas Zeller          |\         E-Mail:         /|  * Never trust a *
 ETH Zurich, Switzerland    | \_______________________/ |  *   computer    *
  (SFIT, Swiss Federal      |  /  zeller@ethz.UUCP   \  |  *  bigger than  *
 Institute of Technology)   | / ..cernvax!ethz!zeller \ |  * you  can lift *
==========================  +---------------------------+  *****************