Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!amdcad!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDos vs Unix wildcards/pathnames
Message-ID: <979@quintus.UUCP>
Date: 4 Apr 89 21:40:17 GMT
References: <11135@ut-emx.UUCP> <10260015@eecs.nwu.edu> <976@quintus.UUCP> <1189@ncr-sd.SanDiego.NCR.COM>
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 48

In article <1189@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes:
>In article <976@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>>... the wildcard matching routines should be written and included in
>>a library ....  the shared library should supply
>>standard routines called InitArguments(), NextFileArgument() and
>>NextNonfileArgument(). ....

>The idea is a good one, but the interface could be cleaner.  Instead of
>being a \new/ set of routines, it should be an extension to the standard
>getopt() routines

This was my first thought.  It still seems like a good idea overall, but
it has fatal 2 drawbacks:  it puts constraints on argument ordering and
option style, and it alters the flow of the program.

There are two ways you may want to write your main():  find all the
switches first, handle them, and then handle all filename args.  Or you
may want to just step through the args as they come, deciding whether
they are switches or filenames, and handling them.  The second approach
fits much better with what I'm trying to accomplish here, since it
allows arguments to be passed as a stream.  For example, you'd want a
compiler to take multiple file names, resetting its state between them,
so that your editor could fire it up over and over.  main() might look
like:

	{   char *arg;
	    reset_switches;
	    for (;;) {
		if (!(arg = NextArg(...))) exit;
		if (*arg == '-') {
		    handle_switch(++arg);
		} else {
		    compile_file(arg);
		    reset_switches;
		}
	    }
	}

I don't think this approach would work with getopt().

I realize that I'm reinventing the wheel, but a different wheel.  I
don't see how this could fit in with getopt().  But I could be all wet:
I must admit I've never actually USED getopt().

-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds