Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!lll-winken!arisia!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDos vs Unix wildcards/pathnames
Summary: A possible solution
Message-ID: <976@quintus.UUCP>
Date: 24 Mar 89 23:18:09 GMT
References: <11135@ut-emx.UUCP> <10260015@eecs.nwu.edu>
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 90

[ Note:  I wrote this a week ago, but our posting SW was screwed up, so
  I'm posting it now, somewhat edited.  It still seems like a good idea
  to me. ]

In article <10260015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
[ about using wildcards in a copy command ]
>In Unix, it would be a detail of the shell, not the program.
>
>Unix commands do not have consistent option specifications, but they ARE
>consistent, as the user sees them, when it comes to wildcards.  This, of
>course, is because most of them don't deal with wildcards at all, because
>they know the shell is there to do it for them.

This is true.  But having the shell do wildcard expansion is a
double-edged sword.  In AmigaDOS, you can type

	2> zoo x foo README *.doc *.man

whereas under unix, you must write

	% zoo x foo README '*.doc' '*.man'

It has been suggested that shared library routines be written that
enumerate files matching a given pattern.  Peter da Silva pointed out
recently that if you do this, then programs that launch other programs
don't have a convenient way to pass arguments that might contain
wildcard characters.  This is particularly serious because it is likely
that hackers will patch in their own wildcard-matching code, so
programs can't really guess what the wildcards ARE.

I'd like to propose an alternative approach that solves this problem,
and has a few other nice properties, too.

First, the wildcard matching routines should be written and included in
a library (exec?), and the other routines I describe below should use
them through the library base, so that people CAN patch in their own
wildcard matching code.  Additionally, the shared library should supply
standard routines called InitArguments(), NextFileArgument() and
NextNonfileArgument(). They would be used like:

main(argc, argv)
    int argc; char **argv;
    {
	char *arg;
    	InitArguments(argc, argv);
    	while ((arg=NextFileArgument()) {
	    ... do stuff with arg ...

Here are the nice properties of this approach:

    1.	It solves the wildcard problem.  The system does the wildcard
	expansion for you.  And it doesn't do it if you call
	NextNonfileArgument().

    2.  It is an interface that can be used for both CLI and Workbench.
	I think it is very important that this be achieved, however it
	is done.  Of course, this doesn't do anything for the harder
	problem:  a common interface for launching CLI and WB
	applications.

    3.  It actually allows programs to be controlled by other programs,
	given a few more library routines to spawn such a program and
	feed it arguments (which would solve the hard problem mentioned
	in #2).  The controlling program could feed the controlled
	program its arguments one at a time, as it determines them.
	It's not as sophisticated as AREXX, but it's free:  the
	controlled program doesn't have to do anything special to be
	controlled.  Say the program in question is a compiler.  It is
	written to compile many source files, and your editor spawns it
	and feeds it the name of your source file every time you ask it
	to.  And the compiler complies by compiling.  The controller can
	tell the task is completed when the controlled program asks for
	the next argument.  (We have to be really careful here, since
	the controlled program may be collecting all the arguments,
	waiting for the last one before it does anything.  There should
	be a way for a program to specify that it is doing this.  Still,
	many programs do fully process one argument before moving on to
	the next.)

    4.  It allows arbitrarily many arguments to be passed.  In unix,
	there is a limit on the number of characters in a command AFTER
	FILENAME EXPANSION.  This approach doesn't have that flaw.

This is a very rough sketch.  I could be more specific if anyone is
interested. 

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