Re: What about a glob standard method in Ada.Command_Line ?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 24 Aug 2010 19:10:14 +0200, Georg Bauhaus wrote:

> On 24.08.10 18:04, Dmitry A. Kazakov wrote:
>> On Tue, 24 Aug 2010 17:42:17 +0200, Georg Bauhaus wrote:
>> 
>>> To me, directory search based on file content ("second order search")
>>> seems rather unusual as a first step.
>> 
>> Surely it is. Don't you look for text files, ada source files etc? 
> 
> No. I look at file names when I scan a directory.

Really? What for anybody would scan directories? I would say that almost
any file search is content-type based, e.g. "ls *.ads". Specific names and
time stamps are not so frequent and almost always intermixed with a content
type constraint.

>> Those
>> are called *content type*. Whether the content type is reflected by the
>> file path and in which form is OS-dependent.
> 
> Is there an OS that reflects a file's content in its path?

MS-DOS, Windows, VMS, RSX-11

>>> Case-(in)sensitivity is easily handled by text pattern matching,
>>> with existing Ada.
>> 
>> It cannot be handled.
> 
> Sure can, for file names.
> But whether the names "Readme" and "README" refer to two different
> files in a directory is another matter, just like the file
> "Frodo.txt" may refer to the same file as "README" and "Readme",
> in Unix file systems, NTFS, and others that support inodes with
> multiple links.

Does the wildcard pattern "R*" match "readme"? Does it match "R�cken", when
� is (16#c3#, 16#bc#) (UTF-8)?

To make patterns work you have to abstract file paths in an OS-independent
way and then define patterns over that abstraction. Naive string patterns
will never work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de