Re: Ada.Command_Line and wildcards

[Georg Bauhaus <bauhaus@futureapps.de>]

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
tools. For me, this counts as part of the design of Unix.

>  modern shells
> support

Yes, it is a good thing that modern shells support... ,
and I find reading tar names from pipes a natural extension.
(Anyone using cpio, besides comeaucomputing.com? ;-)
Incidentally, in a more limited environment like DOS,
programs tended to have an @-parameter for reading things
from a file. Simple, but parameterizing a program then is more
like assignment to temporary variables instead of using 
elegant functional pipes. And there is no garbage collection,
the @-files are still there when the program has finished :-)


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


> > Will REXX programs
> > look the same?
> 
> The same as what?

The same as the expressions above.

> > 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.). Unix operators write.
Unix shell program authors write. 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
writer? (Of course, if your audience consist of readers who read nothing
but "Unix stuff" they will be well served with just abbreviations.)



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


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


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



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



> 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. (And DOS, too.) I'm a Unix user by choice.
But I can't modify every Unix system I have to use on a daily basis.