Re: Ada.Command_Line and wildcards

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

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. And since I already recommended some other shells (that
have a more regular syntax) that should have been clear enough.

> tools. For me, this counts as part of the design of Unix.

But the <censored> syntax of the shell has nothing <censored> to do
with a design choice "of Unix". It is not fixed. (This argument tires
me -- have you even tried to understand what I wrote before?)

>>  modern shells
>> support
>
> Yes, it is a good thing that modern shells support... ,
> and I find reading tar names from pipes a natural extension.

So? That interesting does not count as a positive point with Unix for
you, whereas the syntax of a shell built for a 16-bit processor (the
pdp/11) and kept out of tradition counts against Unix, despite the
fact that it is not an immutable part of the design?

<...>


>> > What is the reason that the Unix design choices do not help prevent
>> > complex, strongly coupled, highly dependent pieces of shell
>> > programming?
>> 
>> Neither does Ada: You can write strongly coupled amorphous code in any
>> language. And the shell is, I repeat, no programming language, but a
>> command language. 
>
> I disagree. The Unix shells are programmable, this is one of
> the things that made them different. So there is programming
> going on. 

Your choice. Don't complain to me if you use the wrong tools. Other
people have switched to perl or python for things like this (cron
jobs). 

> It's fun, I spent almost half the day preparing a
> cron job, enjoying varname=${1:-$(date +%Y-%m-%d)} and such.
> Sparingly though, as others in the shop might want to read
> this shell script.

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

Thanks.

>> > Will REXX programs
>> > look the same?
>> 
>> The same as what?
>
> The same as the expressions above.

And? Will they? Probably not. REXX had another syntax AFAIR. BTW even
C programs, Python, FORTRAN and Plankalk�l will not look the
same. What does that tell us?

And yes I'm deliberately obtuse now, since you alway just hint on
something offering spurious anecdotal evidence but than fail to spell
out your complete reasoning (which usually cannot be completed due to
the spuriousness of the anecdote that is supposed to show something).


>> > Unlike Ada, Unix favors the *writer* over the reader. No surprise I
>>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> I cannot follow your argument here. Ada is a programming language,
>> Unix is an operating system. Are you comparing apples with oranges?
>
> No. When I mean Unix design choices, I mean Unix as it was planned,
> granted, and sold (with troff, sh, etc.). 

Fine. So you're still comparing apples with oranges.

> Unix operators write.
> Unix shell program authors write. 

Yes, *Unix shell* programmers write. You know, a drivers license is
somewhat different from a driver, etc. You're a German, but probably
not Germany (notwithstanding bad image campaigns).

"Unix shell" is something to be distinguished from Unix. Care to
rephrase your statement that I can see what you mean?

> Programmers can use (I hope) some
> shell programming to create software configurations. But considering
> names like "creat" (sic) and the like, traditional short option letters,
> etc., I fail to see how typical Unix abbreviations aren't favoring the

Hm. 'creat' is not in my shell manual.

> writer? (Of course, if your audience consist of readers who read nothing
> but "Unix stuff" they will be well served with just abbreviations.)

 - cacls folder  /e /r user

 - @DUA2:[...]

And don't force me to quote from the VMS source code.

Or perhaps all operating systems have bad design choices? Why then are
you specifically shooting against Unix? 


>> > 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. 
>> 
>> The choice was to make it user settable. I've already quoted the
>> relevant flag elsewhere.

> No, I mean the use case perspective that Hyman has mentioned.

Which was that? I don't think I want to read back through the thread
to interpret this reference.

> You can run the ls(1) program without argument, and it produces
> results that make sense in most cases. Case distinctions come
> into play later.

NO, bloody no. Just turn wildcard expansion off _completely_ AND/OR
turn of that the expansion of a non-matching pattern is the pattern
itself. IT IS USER SETTABLE. Just do it. Case distinctions? What? I
don't even know what you're talking about here.

But I'm certain, I'm missing some finely spun argument here which
would demonstrate that the fact that the users cannot be bothered to
understand their tools and cannot be bothered to change setting -- how
that suddenly becomes the general and deep fault of the Unix design
choices again.

Well -- as far as I'm concerned, you can look for hairs in your soup
as long and as hard as you want. I, simply, find it more productive to
understand stuff and see how I can work with it, instead of waisting
energy to should-have-beens and cant-have-it-like-that where I simply
have no way to force a change now. I've other and better wind mills to
fight.

I'm certainly not saying that Unix is perfect. There is quite a lot of
things I'd improve if I could.

But the things you complain about a certainly either not problems at
all and certainly not important.


>>  A short (or longer) look into shell manual will clarify all
>> these things once and for all, for all "shell commands".

> Every longer look into a Unix subject might clarify.  However, the
> question is whether there should be a need for that much
> clarification in the first place. That's the point.

"That much" is a rather vague criterion. Again we're back to wether a
user/programmer can be bother to learn his tools.

BTW: "Concerning Ada: (Almost) every issue with Ada the ARM might
clarified by a look into the ARM or into Barnes excellent book.
However, the question is whether there should be a need for that much
clarification in the first place. That's the point". 

Do you see NOW how utterly empty such statement are?


>> You're again attributing something to a
>> "difference" between 'ls' and 'echo' that simply doesn't exist, at
>> least regarding the handling of arguments.


>>From the use case perspective there is a difference between echo
> and ls. Why is it better when a user has to learn one or two levels of

He has not. Just turn wildcard expansion off. The feature there for exactly
that purpose.

> indirection only in order to understand how Unix programs interact with
> Unix shell expansion rules? 

> Sounds like: This car has four pedals.
> You will drive better when you learn how to use them. Please note that
> when this car was designed, most other cars needed two operators, and
> they didn't have pedals at all! (Comparing JCL, say.)

More bad mataphors. Always a good way to drag out a discussion until
kingdom come.

What you require, is, that the car doesn't have any pedals and
that the user does not have to understand that a non-running car is
sometimes to be fixed by filling in gasoline, but sometimes by turning
on ignition.

>> And BTW: Unix tools don't "read their arguments expanded".
>
> I mean after expansion has taken place (or not),
> $ strace ls *.pl 2>&1 |head -1
>
> execve("/bin/ls", ["ls", "check.pl", "test_md.pl", "test.pl"], ...
>
> After expansion has taken place, there is something in argv
> that I'm calling expanded arguments. No?

No. _Unix tools_ still don't "read arguments epxanded". The _shell_
provides an optional language to _generate_ arguments. The _Unix tools_
have nothing to do with it.

>> Please, Georg, read and try to understand what I'm writing. Most of
>> what you complain about are features that CAN be turned of
>
> The Unix design choices can't be turned off. ls(1) has a default
> behaviour. That's Unix. 

But you DIDN'T complain about the ls behaviour. You DID complain about
the shell expansion, that CAN be turned off.

You're completely mixing things up. Does it even make sense to
continue this "discussion"?

>(And DOS, too.) I'm a Unix user by choice.

Who has such friends doesn't need enemies.

> But I can't modify every Unix system I have to use on a daily basis.

.profile, .bash_profile. cvs.

Yes, you can. And if you don't have a single system image or a
deployment mechanism for configurations on disjoint systems that again
is not a Unix design choice, but perhaps a choice of your system
administration / administrators.

Regards -- Markus