Re: Ada.Command_Line and wildcards



Dear Georg, Dear all,

Georg Bauhaus <bauhaus@xxxxxxxxxxxxx> writes:

On Sat, 2007-02-24 at 12:46 +0100, Markus E Leypold wrote:
Martin Krischik <krischik@xxxxxxxxxxxxxxxxxxxxx> 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


.

Relevant Pages

  • Re: asterisk in regular expressions
    ... characters to the shell. ... expansion resulted from those globs. ... and 'echo *' echoes an asterisk. ... grep unsuccessfully matches the stdin string "now" to the file name list ...
    (comp.unix.questions)
  • Re: Questions related to - Arg list too long - error
    ... I'm expecting printf or echo to fail, given that initially, there is ... wild card expansion done for them too, same as ls and friends, but no ... The shell may be able to handle the full wildcard ...
    (comp.unix.shell)
  • Re: Questions related to - Arg list too long - error
    ... I'm expecting printf or echo to fail, given that initially, there is ... wild card expansion done for them too, same as ls and friends, but no ...  The shell may be able to handle the full wildcard ... The shell does the wildcard expansion, ...
    (comp.unix.shell)
  • Re: Shell Expansion in Bourne Shell Script Question
    ... by the shell to all existing files matching the pattern. ... Using 'echo' would yield the same ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". ...
    (Debian-User)
  • Re: Good or bad testimony?
    ... Does it matter how we are or how we behave? ... outright sin, I mean personality traits). ... The reason I ask, is that someone told me a couple of weeks ago that I had a ...
    (uk.religion.christian)