Re: Ada.Command_Line and wildcards

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 22 Feb 2007 16:15:40 +0100, Ludovic Brenta wrote:
>
>> Jean-Pierre Rosen  writes:
>>> Maciej Sobczak a �crit :
>>>> Jean-Pierre Rosen wrote:
>>>>
>>>>> Too bad that Unix behaviour was wrong in the first place...
>>>>
>>>> I don't understand. Shell uses some special characters to make it
>>>> easier for the user to type commands [1]. Wildcards are just an
>>>> example. Consider this:
>>>>
>>>> $ cat *.ads *.adb | wc -l > loc.txt
>>>>
>>>> If you claim that * above should be passed "as is" to the program
>>>> (cat), so that the program can figure out on itself what to do with
>>>> it, then you might as well argue that the program should figure out
>>>> *everything* above. Obviously, that wouldn't be funny.
>>>>
>>> I claim it would be easier to provide a function that expands
>>> parameters, than to force expansion. Or maybe just provide another
>>> function that provides the raw parameters.
>> 
>> There are three such "other functions":
>> 
>> $ cat '*.ads *.adb' | wc -l > loc.txt
>> $ cat "*.ads *.adb" | wc -l > loc.txt
>> $ cat \*.ads \*.adb | wc -l > loc.txt

Case (1) and (2) don't differ in this case. The difference between
case (2) and (3) has nothing to do with file name (wildcard) expansion
but rather how a given string is parsed into word.


>> So could you please explain why you think the Unix behaviour is
>> "wrong"?
>
> It is wrong because it does not clearly define what is a "command line,"
> which makes almost impossible for an application to handle (parse) "command
> lines." 

This is, forgive me, wrong. The "commandline" in Unix is a an array of
pointers to zero-terminated strings which itself is terminated by a
null pointer. Every application is free to interpret the command line
arguments as it likes. The wildcard expansion is a service provided by
a shell and depends on the shell used. Dito parsing a command line in
words. For that reason most applications don't bother to do wildcard
interprestation of file arguments themselves, but exceptions exist.

Putting the language to describe sets of filenames into the shell
makes sense inasfar as (a) there are user specfic preferences and (b)
it guarantees that at least that syntax is homgenously "supported" by
all tools. 

The disadvantage is that for programs directly exec'ed by other
programs, this mechanism is not available.

The unix philosophy of handling the passing of command line parameters
to the programs is, I think, time tested, but people might prefer
other ways to do it. But calling it "wrong" is outright nonsense.

Regards -- Markus


> One could try to argue that there is no need to do it at all, but
> that is clearly not the case.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de