Re: Ada.Command_Line and wildcards

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

Dear Georg, Dear all,

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sat, 2007-02-24 at 12:46 +0100, Markus E Leypold wrote:
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>> 
>> > here. And they got it wrong. Bot Dos and VMS will warn you on:
>>             ^^^^^^^^^^^^^^^^^^^
>> 
>> [...] On which criteria did
>> "they get it wrong"? Where are the specs against which the predicate
>> "right" can be tested?
>
> One criterion is the number of wildcard expansion surprises.
> Not having to mark patterns as patterns (untyped, no syntax)
> creates an immensely flexible and powerful ... mess.
>
> $ echo *.ads   # argument text is a pattern
> *.ads          #   output text is a pattern
>
> $ echo *.adb   # argument text is a pattern
> main.adb       #   output text is a file name
>
> $ ls *.ads
> ls: *.ads: No such file or directory
>
> $ ls *.adb
> main.adb
>
> (On the surface, ls(1) and echo(1) aren't consistently
> interpreting *.ads, one is reporting an error, the other
> is reproducing input. "But that's as defined, you ...
> If you can't be bothered to RTFM!")

Exactly ... that is as defined. I take it you're not overly familiar
with the Unix shell? Since this has nothing to do with " ls(1) and
echo(1) aren't consistently interpreting" but with exactly on quirk
the expansion (in the shell!) has:

 1. Expansion does always take place if the word is not quoted.
 
 2. If there is no file corresponding to the pattern, the result of the expansion
    is not '', but rather the pattern itself.

Thus we have

 echo *.ads --> echo '*.ads'    --> output: *.ads
 echo *.adb --> echo 'main.adb' --> output: main.adb

 ls *.ads   --> ls '*.ads'      --> try to stat() '*.ads', doesn't exist
 ls *.adb   --> ls 'main.adb'   --> try to stat() 'main.adb', output result

So ls and echo just act differently because they simply try to do
different things with the data they get passed: echo doesn't tell you
an error, because (as specified) it just has to echo it's arguments.

If you would have quoted, you'd have got the following results (note: no expansion takes place in all cases):

 echo '*.ads' --> output: *.ads
 echo '*.adb' --> output: *.adb

 ls '*.ads' --> try to stat() '*.ads', doesn't exist
 ls '*.adb' --> try to stat() '*.adb', doesn't exist

You see: Everything uniform, no heterogeneous behaviour at all.

I'm thus happy to note that your analysis seems to be based on a
certain lack of understanding how Unix or the Unix shells work. I'd
also like to insinuate that for a number of other contributions to
this thread. That can happen and certainly is no sin, but I humbly
suggest it might be advantageous to understand a thing before
asserting "it's all done wrong". At least it helps to get applicable
arguments instead of a bunch of misconceptions.

There is one point in what I elaborated where the Bourne shell might be
open to criticism: Point (2): If there is no file corresponding to the
pattern, the result of the expansion is not '', but rather the pattern
itself.

This has been a deliberate design choice to allow omitting the quotes
in many cases for convenience -- at the price of making it difficult
in some cases to assert wether the argument passed is a non-matching
pattern or the result of a successful expansion (this is hardly ever a
problem, not in interactive mode and good shell programmers know how
to handle that case).

But again this is no "as Unix handles arguments to programs" issue,
but rather choice taken in the design of specific shell language which
should provide enough power to start, stop, connect programs and at
the same time be easy to use interactively (i.e. without too much
typing).


> Since Unix shells use mostly text to represent almost all 
> information, the user is advised to remember text substitution
> pitfalls like the one above. Shell programming, for all its
> power, is like using Unchecked_Conversion by default, so to
> speak. In case of errors then, keeping track can be quite tricky,
> even more so when there is indirection, for example through
> popular backtick evaluation, as in
>
> $ foo=`echo .[a-z]*` ; some_cmd $foo ...

Well -- backtick is "out" anyway for the more complicated
cases. Especially when writing scripts I suggest to use $(...) --
which gets the nesting right.

>
> (run in a directory where there aren't any hidden files.)
>
> Caveat scriptor, the computer isn't programmed to help us
> here with type checking, OOD, etc..

Just use the scheme shell if you don't like Bourne shell. :-) 

But it is something you have to get used to, to properly quote ANY
arguments.


> That said, I'm looking forward to running Plan 9 again, on a
> virtual machine :)

Last time I checked (rather a bit ago that was) it couldn't run on
vmware or bochs: Has that changed?


Regards -- Markus