Path: utzoo!attcan!uunet!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: SKsh completion bug.
Message-ID: <1213@lpami.wimsey.bc.ca>
Date: 8 Mar 90 22:39:58 GMT
Lines: 95
Return-Path: <lpami!lphillips>
To: van-bc!rnews

In <682@xdos.UUCP>, doug@xdos.UUCP (Doug Merritt) writes:
>The problems with that are:
>	1) Pervasiveness/universality: if it's not in the shell, that
>	   generally means that feature is not universally available.
>	   So I have to remember which commands allow it, which do not,
>	   which support one flavor of wildcarding, which allow another,
>	   which use both, which have Super Wildcard Expansions, etc.
>	   So this is also a "consistency/documentation" argument.
>	   And this is precisely the problem I currently have.

As you point out, it is a 'consistency/documentation' problem, not,
as  you mention earlier, a 'not in the shell' problem.  As you well
know, there are commands for which shell expansion of wildcards is
innappropriate, and because of this, it is sometimes desirable to
allow the program to determine the way to handle expansion of the
wildcards.

>	2) No, you don't need "unix-like commands". Essentially all
>	   reasonable utilities support a command line list of files.
>	   Even if they support wildcards, they will not object to
>	   what appears to be a wildcard-free list of filenames typed
>	   by hand.

They may or may not object. This is the whole point of having
shell expansion; that programs will be written with shell
expansion in mind if that's the way the system works, and will not
object to extra arguments.  With expansion left strictly to the
program, anarchy abounds, and a program may choke, do the wrong
thing, or ignore everything past the first filename without
telling you.

>	3) Duplication of effort/code size. When every command has its
>	   own wildcard code, it not only wastes code space, it also
>	   (probably more significantly) wastes the time of the developer
>	   who had to reinvent the wheel one more time.

As I mentioned earlier, sometimes it is desirable for the program
to expand the wildcards. A case in point is where the wildcards
specify filenames that are not currently in existence. One day I
typed 'mv *.foo *.bar' on a Unix machine, and was appalled to find
out that it could not be done. Why should I have to remember the
way a shell treats wildcards for non-existent files (and to
subsequently have to write it as a 'foreach' loop, when there is
a perfectly good way to avoid both this problem and the problems
inherent in program expansion of wildcards?

>So, no, it's not just to provide a Unix-like environment. It's because
>it's smart. The only (arguably) better way is to provide the facility
>in a *standard* system library (ARP may reach this status but it ain't
>there yet).

Now there's the ticket. A simple call to a system library that
will expand the wildcards, callable by the program _when
appropriate_. Make it easy to use and cheap in code size, and it
will be taken into consideration and used by programmers. In the
example above, the 'mv' command would expand the first argument
with a call to the system routine, and would either handle the
second argument itself, or pass the second argument to the
wildcard expansion, along with the first argument as the target of
the expansion, rather than whatever currently exists in the file
system.

> This makes it a little less universal, in that some boneheads
>will still write programs that don't *use* the system facility (as
>previously established on all the O.S.'s that do this). But it gets
>around the limited expansion space problem.

Boneheads abound. We cannot ever guarantee that all programs will
be written correctly. About all we can do is to provide the
facilities for doing the right thing, document them in a way that
they are understandable (lets make it more than strictly C
oriented documentation), and hope that the errant programs are
in the minority.

>It also potentially allows wildcards to be used even in e.g. requesters,
>which the shell approach does not.

Yes, and a requester could call the same library, selectively. If
the requester required some list criteria other than existing
files, it could be passed the list of names to use.

We have a machine in which the wildcard expansion philosphy is not
set in stone. Let's not make the mistake of accepting either of
the 'extremes' of philosophy. Let's look at how we can have the
best features of both philosophies.

-larry

--
Entymology bugs me.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+