Re: Ada.Command_Line and wildcards

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

"Adam Beneschan" <adam@irvine.com> writes:

> On Feb 23, 11:04 am, "Hyman Rosen" <hyman.ro...@gmail.com> wrote:
>> On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>> wrote:
>>
>> > Yuck -- bad design!
>>
>> The designers of UNIX didn't feel that it was necessary for every
>> program to incorporate a wildcard expander when that could be done
>> externally. Back then keeping programs small and simple was a virtue.
>>
>> > And there's no wildcard that means "all subdirectories, recursively".
>>
>> And no wildcard that means "all files that have changed since
>> yesterday".
>>
>> There are an infinite number of things that you might want to specify.
>> Many of them won't have been thought of when the programs which could
>> benefit from them are written. That's why it's better to do these
>> things
>> externally, and just have one program to modify when you come up with
>> your new wildcards.
>
> But as has been said several times before, the OS could have provided
> a service that could have been called iteratively to return the file
> names, one at a time.  

Well, it does. It's called 'find' and pipe like this:

  find dir1 dir2 -name '*.ada' -size -5000 | command_that_reads_its_files_from_stdarg

It depends on the tool wether it supports reading its arguments from
stdin. You can always roll your own by providing an appropriate shell
script wrapper if it doesn't.

And if everything fails: Nobody _forbids_ your tool to expand the
command line arguments on its own.

> That's how VMS does it.  

So?

> This arrangement would solve both the problems you mention
> above---keeping the applications small and simple, and allowing for
> new types of wildcards without having to change the application.

See the solution with find and the option(s) to pass arguments and
lists in temporary files.

Regards -- Markus