Re: Ada.Command_Line and wildcards

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> 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.

If you mean by "text substitution" evaluating arguments and passing
them to procedures / tools, then you're right: THis is something I
don't want to miss. If you really mean text substitution, neither the
scheme shell nor i.e. iphyton are based on text substitution. They are
based on proper programming languages with properly delimited strings
and functions.

>
> I really do know how to melt and loosen Unix design choices
> and replace these choices with things I need today, on my machine.

Good ...

>   *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.

I admit that, but I find your use of "Unix" still problematic
here. First, the kernel itself doesn't know ynthiong about text
substitution. Second, text substitution is something implemented in a
lot of Unix tools (cpp, m4, sed, awk) and it is often exactly what one
needs to process text.

The feature has ben misused in the past, but that is not restricted to
Unix: We find wild pattern matching on input (insterad of proper
parsing) and "template expansion" (an euphemism for text substitution
:-)) all over the place. XML is also based on text -- with all the
consequences this has.

> (2) Omissible text has consequences today, by design.

I don't quite grok what you mean by "ommissible" here. If you mean
that quoting is not obligatory -- yes, that is the hallmark of many
interactive command languages, a number of them not grown on Unix at
all. It's the spirit of the 70s ... ;-).

And BTW: I'm not sure they were wrong.

I wouldn't want to use Ada as an interactive command language. There
are, I think, ways to get (1) type safety, (2) proper quoting without
too much overhead. I, personally, would built a new generation shell
system on, ahem, OCaml, because of the type interference and because
functional composition might take the part pipes have played in the
past. Something like

  dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) | flatten | print dir_entry_long

should be possible.

> 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. 

No. I do think you use the word design in rather too broad a
sense. Else we could never change ynthing without "changing the
design".

One must perhaps live with the notion that no OS is just amonolithic
complex of design choices. It is not simply a "design change" if I
(user) change to another shell (that is designed to be user
replacable, BTW). The syscall API doesn't change. The compilers don't
change. The configuration system doesn't change. The libraries don't
change.

Of course you can lump all in one and ignore that a system like Unix
is built up of layers. But then I think you're missing something. At
least the chance to understand Unix better and learn to live with it.

The decision to have text substitution in the default shell, doesn't
permeate Unix. Most of the parts of Unix a blissfully ignorant of that
and that is good as it is, since that means we can have an embedded
Unix with e.g. busybox as shell, which does not do all the fancy stuff
bash does -- and we can still install/use/integrate basically the saem
tool set.

So no -- e.g. text subtitution is no "Unix design choice".


> 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.

Well, that is the nice thing with Unix: Many of those "you have to
learn to use a new thingy" are quite optional. Shells are per user
configurable. The use of specific programming languages can be decided
per project and so on. You never need. You can.


> 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. 

Of course if I didn't want to use Bliss at VMS, I always had the
choice to use Pascal. Does that indicate a "design flaw" in VMS (they
never should have had Bliss at all)?

Hardly.

> (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.)

Exactly. So you continue to brand chances as proofs of flaws. Bad, in
my opinion. If you don't like the shell, use another. If you don't
like a programming language (shell, C), use another (Python, Ada,
...). Thousands of programmers never had problems with old shell or
the existing languages. That you have a problem with them doesn't make
them (a) design choices or (b) bad design choices. They weren't wrong
to be there in the beginning (in the 70s there WAS no alterntive
design nor a resonably priced machine that could carry it), that they
are still here today is also no design flaw (but compatibility, pure
and simple). BTW, I not, we're back to one of the old C vs. Ada
themes: Why don't people _change_ to other languages etc. -- Well, as
I have already alborated often enough, there are reasons.

That bourne shell (and C) are still there doesn't make them bad design
choices for the very reason that _you_ as user and developer have the
choice not to use them, but still use Unix.


> By analogy, if we were talking about why they chose to make "tagged"

No analogies please. They are like a green potato thrown after a
running dog and don't scratch the mustard. "Hngh?" you say? You see,
exactly that: Analogies are pretty bad to discuss somethingm because
they are often difficult to understand, their validity is limited and
needs to be subject of another discussion (as if we hadn't enough of
that already).

> 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.

Well, see. Again you're using a programming language as an analogy for
an operating system. Instead of talking about first principles to
built OSses and how to best structure user interaction with the OS. 

That does bring us nowhere. 

> Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984).

?? entire things ??

> 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.

More (bad) analogies ... :-(

> By turning off shell expansion, no one can change the Unix design
> which offers shell expansion. 

Aaah, I understand: Its bad to offer functionality, even to those
users that want it?

> (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).

My bad. I shouldn't have given the impression to know anything about
Unix (soft wired knowledge).

So if I know about something well enough it must be _hard_ wired? Get
real, Georg.

If you want to know how much functionality in Unix is really hard
wired, I suggest you study some of the development and porting history
of Bell Unix. There hardly seems anything that was no expendable at
one time or other (from users to full fork/exec).

>> 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.

It is good that you see that. So we're actually back to square 1: (a)
A number of anectodes "things I found surprising when working with
Unix" (or should that be "thing I pretend to have found surprising",
since you always insist that you know very well how all that works,
only you think that other <whatever>) and (b) a number of assertions
that Unix is badly designed in some (IMHO minor) points that are not
connected to (a).

The problem as I see it, is basically, that we're discussing straw
man: Since you insist you can work with it and it is not really your
problem, we can only talk about problems of others. Or about problems
of the industry in general. That would require either something more
than narratives about your experiences (you don't have a problem,
rembember) or trying to establish sonme first principles on operating
system design and then relate the Unix design to that (I don't think
we'll be able to lead that discussion).

>> Thanks.
>
>
>
>>  What does that tell us?
>
> [REXX, scsh, etc.] It tells about alternative designs. About a way

REXX ahs never talked to me. As far as "seeing" things goes, I can
agree that REXX, C, Python, Ocaml, Bourne shell and Perl programs are
all different. Their beauty or ugliness and their relative merits
though all lie in the eye of the beholder. Since the programs don't
talk to me, a bit more reasoning would be required to establish some
conclusions here.

> to compare design choices by their consequences. About what can be
> done when it comes to successor designs.

Since I'm not able to deduce the existence of chocolade pudding and
income tax from "cogito ergo sum", abit help would be required to
point all those conclusion out to me. But before you do that, perhaps
it would be useful to formulate a hypothesis / lemme that relates to
out Unix discussion and woul actually change the course of our
argument and only after we have indeed established that, try to
somehow corroborate that hypothesis / argument with conlusion drawn
from the evolution of REXX. I doubt that is possible, except in very
general and useless sense, since REXX is a language, Unix an OS and
you'd probably also say something about the validity of transfering
conlusion from one domain to the other.

>
>> 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.

Good. Should haves are indeed not my bailiwick. How to change things
to the better are more in my direction.

Rant on against the shell, if you like. The shell (I say it again) is
not Unix, a formulation youd use again and again.

> Much like "creat" (without the final letter 'e') could have been
> named differently, as told by its creator.

Still, creat is not in my shell manual. The topic is still shell
related isn't it?

> Or should I accept that the Unix design was flawless in the
> first place, 

Admitting that Unix certainly has flaws is quite different from
admitting to your specific points. Probably "X has some flaws" is true
fro any man made X.

> 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.


What nonsense. You undertand the words "history artefacts". Is DUA0
named DUA0 because it is perfectly understandable or for some deep
design choice or because of historic development?

>>  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

Aaah! So the VMS shell is just so much less work than the Bourne
shell? I had the impression that most of the additions to the shell in
V7 had the purpose to save work (also to the tool writers).

> less configuration, more or less training to achieve the same
> level of productivity, etc..

I'm sure you can prove that Unix fails miserably in all that? Esp. if
compared to better or newer operating systems? But let's not start
that discussion again.

If you just want to _state_ how much more complicated _you_ find the
Unix shell and working with Unix (than ...?), we can just leave it at
that. It's hard to contradict testimonies of personal experiences that
properly start with "I". It's only conclusions we can dispute.

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

Yes it is used. But I do not understand the drift of your
argument. Using argv[1] does not expand the argument, does not relate
to quoting or the shell. It's outside of the scope of the world view
tools have: They get arguments and they process them. Some of them
even expand them (mcopy, e.g. or find) others use them as they find
them. That is, indeed, exactly as it is in VMS (we've been refereing
to VMS a number of times as a counter example). But in the sentence
"the tool reads the expanded arguments and they do it wrong" there is
either a hidden actor somewhere inplied (the shell) and that means
"they do it wrong" can't mean the tools, but should refer to the shell
OR the expanded is somwhat out of place: "the tools read the
arguments. Fullstop".

But you snipped that part of my last post, so maybe I'm relating you
question to the wrong subtopic.

Summary: Yes, argv[n] (0<=n<=argc) is used to retrieve the command line
words. But how is that related to the discussion on the Unix shell?

Regards -- Markus