Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen <sparre@nbi.dk>]

Georg Bauhaus wrote:

> Unlike Ada, Unix favors the *writer* over the reader. No surprise I
> think. But damn right?

Considering that the Unix shell is created for _interactive_ use, this
is certainly not a surprise.

But with our new, fancy, interactive shells (like Zsh) it may be time
to paraphrase Preben Randhol's signature:

   Saving keystrokes is the job of the interactive shell, not the
   programming language.

With GNU tools I generally use the long version of the command line
arguments.  In interactive use it is not significantly (if at all)
slower than the short versions, since Zsh helps quite a lot.  And in
programs it improves readability.

> When it comes to echo *.ads, a decision was necessary as to what
> should happen when there is no matching file name. The choice was
> not: reflect this fact and produce the empty result.

Which might have been nice.

> I wouldn't mind programs that just read their arguments unexpanded
> and call the OS expansion service, an iteration device for example.

If that is _the_ way to scan a directory for files, it may be possible
to get (practically) all programmers to use it, and thus give a
uniform file name pattern expansion service.  But what rules should
this uniform service follow?  Just plain old fashioned globbing?  Or
the extended Zsh version?  Or something completely different?  Can we
make the pattern matcher user selectable?  (Programs would of course
have to select one, to work consistently with internal patterns.)

> And if there is no matching thing, then *every* program consistently
> produces empty results!

Yes. :-)

> One difference, then, is that an ls will consistently produce
> nothing for no argument. This will require more typing when you want
> something, for example ls -d "*".

Couldn't one just expand the rules for "ls", so calling it with the
name of a directory corresponds to "ls <dir>/*" (in globbing terms)?
Since no explicit directory means ".", then "ls" will correspond to
"ls ./*" and work like the more lazy of us would like it to.

This would be different from calling "echo" without any arguments.
But it would be so because of the _meaning_ of the arguments.

> I don't think any Unix programmer will see the benefits of more
> typing. But having gone some way through the Ada experience I think
> this the right thing.

With a sufficiently smart interactive shell, we can probably cut down
on the typing at the same time as we improve the handling of big
directories.

> Or with this change, if calls to the expansion service should not be
> part of Unix programs, why not have
>
> $ ls $(expand "*.ads")

Much too long to type.  And it wouldn't solve the "too many arguments"
problem.  If there should be configurable file name pattern matching,
I would rather do it using an environment variable:

   FILE_NAME_EXPANSION=globbing ls *.ads

> (I'm not a fan of large directories when we do have a hierarchical
> filing system, but again, who am I to suggest that a program be
> redesigned to use a hierarchy of directories for file storage.)

When I store more than 10_000 messages from comp.lang.ada; how should
I distribute them in a hierarchy of directories?  I might for example
need to grep them for Preben's signature.

> For large jobs, ed(1) is the most efficient editor

For some reason I just use vi(1) and sed(1).

Greetings,

Jacob
-- 
�When in Rome; burn it�                        -- Diziet Sma