Re: Ada.Command_Line and wildcards

[Georg Bauhaus <bauhaus@futureapps.de>]

On Thu, 2007-03-08 at 10:16 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote:
> >>  Again let me differentiate that the syntax has nothing to do
> >> with Unix design choices, that is "only" a shell thing and the shell
> >> can be replaced (already has more than once).
> >
> > Well, I find it difficult to imagine Unix without the
> > programmable shells, intended to be used as glue between the
> 
> Aaaargh!! Did I say that? No, no, no! I said "replaced", not
> abandoned.

I don't argue against using Unix, and not against configuring
Unix work environments either. The whole thread is about the 
consequences of some longstanding Unix design choices which
then established what can know be termed the Unix design.
Text substitution is still part of every successor design.

I really do know how to melt and loosen Unix design choices
and replace these choices with things I need today, on my machine.
  *BUT*:
(1) Textual substitution as in the original Unix design keeps
having consequences today, with or without new shells, with or
without pattern expansion. This is just a fact of life with Unix,
by design.
(2) Omissible text has consequences today, by design.

These are the design choices in question, see the prior postings
to this thread.

Suggesting replacement parts for pieces of Unix really means
suggesting to change its design. It isn't turned into Windows NT
by these changes, but someone coming from Unix will have to
learn how to use the new parts.

You keep listing perfect examples of how to improve on the Unix design,
by replacing parts of the design (e.g. different shells, hence
differently designed shells), new features, or by suggesting
to configure environments should it be necessary to overcome
default settings as per design. Fine. So the original design
has its flaws. (BTW, it is part of the design of
Unix that I *can* do these things. There is very little one
can comfortably do in this regard using cmd.exe without
extensions.)

By analogy, if we were talking about why they chose to make "tagged"
a keyword during the Ada 9X process and not make every type implicitly
tagged, we are talking about the Ada design (choices). For the notion
of Ada design, it doesn't matter that there can be Ada-like languages
that have implicit tags for every type. And it doesn't matter that I
can use Ada without Ada.Text_IO, or without tagged types; both are part
of the Ada design, no matter what. And this has consequences and
I have to know them, for good or bad.

Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984).
You don't have to use either Unix or Ada in their entirety; you can
replace some parts, which is good.
If you used an encoding aware string type in place of Standard.STRING
etc, your program might be better, but you don't change the Ada
design choice for String types. You only avoid the consequences of the
original design. So the original design has consequences. Some
parts of the original design are just irreplaceable.

By turning off shell expansion, no one can change the Unix design
which offers shell expansion. (I doubt it is really used as just an
option in typical Unix use, but rather taken for granted.)
In particular, some parts of Unix design are just hard wired, as
you have demonstrated a number of times by informing us about your
knowledge of the many wires (mechanisms).



> Thanks for sharing that story with us. The conclusion for a more
> general view on Unix is ... -- Please complete the following sentence:
> 
>   Georg B spents almost half the day preparing a cron Job. From that
>   we must conlude that Unix __________.

I'll appreciate your view, although I trust no one will hurry to infer
Unix design properties from my having fun when working with Unix.

> Thanks.



>  What does that tell us?

[REXX, scsh, etc.] It tells about alternative designs. About a way
to compare design choices by their consequences. About what can be
done when it comes to successor designs.


> But I'm certain, I'm missing some finely spun argument here

Yes. I think you are missing the argument of this thread. That the
parts that make up Unix, with Bourne shell and C shell and expansions,
could have been designed differently in the past WRT how to
use textual substitution and WRT the amount of omissible text.
Much like "creat" (without the final letter 'e') could have been
named differently, as told by its creator.

Or should I accept that the Unix design was flawless in the
first place, and that programmers should just have learned
to omit the final letter from the word "create"? I think this
example is representative of some Unixisms. They are fun, but not
to be repeated as designed.


>  Again we're back to wether a
> user/programmer can be bother to learn his tools.

We are back to whether a design choice makes using a system
more or less work. Whether it has more pitfalls, requires more or
less configuration, more or less training to achieve the same
level of productivity, etc..


(BTW, are you saying that the expression argv[1] is not used when
reading arguments from the command line?)