Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!sri-unix!hplabs!tektronix!uw-beaver!uw-june!geops!uw-atm!james
From: james@uw-atm.UUCP (James M Synge)
Newsgroups: comp.sys.amiga
Subject: Re: Pattern Matching & documentation
Message-ID: <70@uw-atm.UUCP>
Date: Sat, 6-Dec-86 01:00:55 EST
Article-I.D.: uw-atm.70
Posted: Sat Dec  6 01:00:55 1986
Date-Received: Sun, 7-Dec-86 22:21:52 EST
References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3135@ece-csc.UUCP>
Organization: Dept. of Atmospheric Sciences, U. of Washington
Lines: 21
Summary: Right on! Wildcard expansion by default, but not forced on you.

In article <3135@ece-csc.UUCP>, mark@ece-csc.UUCP (Mark Lanzo) writes:
> An idea:  if there are any spare bits in a file's "protection"
> code (read/write/execute/delete/archive/whatever...), maybe one could be
> defined as a "Filename expansion" bit.
> ...
> So, what if the system by default expanded filenames on the command line
> before calling a program, UNLESS some special bit in the file's access
> code was set?

   Thats EXACTLY the way it should be done.  I use the Primos OS which does
things this way.  So, if you write a 'normal' program and don't do anything
special, the command processor automatically handles wild card expansion
(and many other features).

   The bits can either be in the executable format, or in the file header,
as long as there is a standard.
-- 
---------------------------------------------------------------------------
James M Synge @ Dept. of Atmos Sci, U of Washington (@ DEC in NH, January)
VOX: 1 206 543 0308 (W)   UUCP: uw-beaver!geops!uw-atm!james
     1 206 455 2025 (H)   ARPA: geops!uw-atm!james@beaver.cs.washington.edu