Re: Ada.Command_Line and wildcards

[Georg Bauhaus <bauhaus@futureapps.de>]

On Mon, 2007-03-05 at 14:20 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
> >> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
> >> 
> >>     Georg> $ echo *.ads
> >> 
> >> Get a real shell !
> >
> > Sure. Point is, we had been talking about Unix design choices
> > not about what I am seemingly doing (doing according to you
> > and others, that is, which is not what I'm doing :).
> 
> 
> Hi Georg, 
> 
> As long as your arguments are heavily based on your experience and
> practice we have to talk about what you're doing or we can stop
> discussing.

Right, but my experience, while not based on thousand of observations
of Unix users, includes some of this. Moreover, some arguments
are purely technical, like the many "white space thingies" in
shell programming. Or the drastic semantic consequences of minor
changes in quoting-or-not-or-differently type-less text that have
been mentioned a while ago.

This is very much unlike Ada :-)

> Most (auto-) configuration concepts are really bad hacks. They are
> hardly Unix design choices. The wrong place to fix that is to change
> the shell or the prcess model.

Right. But don't you think that this kind of use of Unix tools
must be investigated such that the Unix design choices are taken
into account while doing so? What is the reason that the Unix
design choices do not help prevent complex, strongly coupled,
highly dependent pieces of shell programming? Will REXX programs
look the same?

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

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. This might
have had other consequences somewhere else. Instead, it
was to produce the pattern itself--which is very different from
a file name. echo(1) is a highly overloaded function, so to speak,
very flexible. So flexible indeed that it takes some time to
learn how this one command interacts with all sort of things Unix.

That's unlike what ls produces. But it is consistent with ls and with
the other uses of echo by 1..* mental indirections. Now, what might
be an alternative design choice?

I wouldn't mind programs that just read their arguments unexpanded
and call the OS expansion service, an iteration device for example.
And if there is no matching thing, then *every* program consistently
produces empty results! 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 "*".
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.

Or with this change, if calls to the expansion service should not
be part of Unix programs, why not have

$ ls $(expand "*.ads")

It isn't more difficult to understand, and it doesn't work with
large directories either. It requires that shell commanders
say what they want, though. (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.)


> > system settings. But these seem to be the new Unix hackers' favorites.
> 
> new Unix hacker?

There was a time when you knew that logging into a Unix system (HP,
BSD, etc.) would give you a very basic setup. But you could use the
entire Unix Toolbox, without surprises. Reaping the benefits of some
shell programming would give you a productive environment.
  Today, the new Unix hackers try to give you a "productive" environment
by default. You may have to expect AI-driven completion, and lots
of aliases, and not only will learning some Unix shell programming
still be profitable, but in addition you have to learn how to bridle
typical default shell setups. Unix used to be configurable (after
mastering the design choices). Now it is pre-configured... I guess
the consequence is that many users think they won't need to learn
shell programming.

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