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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 24.08.10 18:04, Dmitry A. Kazakov wrote:
> On Tue, 24 Aug 2010 17:42:17 +0200, Georg Bauhaus wrote:
> 
>> On 24.08.10 16:24, Dmitry A. Kazakov wrote:
>>> On Tue, 24 Aug 2010 12:27:01 +0200, Georg Bauhaus wrote:
>>>>
>>>> procedure Start_Search
>>>>   (Search    : in out Search_Type;
>>>>    Directory : in String;
>>>>    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>>>>    Filter    : in Filter_Type := (others => True));
>>>>
>>> You just do not need patterns in directory search. The first reason is that
>>> the underlying  OS does not support that arbitrary stuff anyway.
>>
>> It is my program that matches file names against a pattern, not the OS.
> 
> Right, this is why an argument to efficiency would be invalid.

Efficiency of glob is unpredictable.  Linear scans of a directory
are slightly different in this regard [*].
And yes, both the Pattern parameter in current Directories.Start_Search,
or Matcher above could really be dropped. Not much will be lost, if
selecting file names can be performed later.


>> 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.


> 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?


> Patterns cannot work here.

Patterns are intended for names, not content.

(It is odd that most contemporary file systems and archive formats
support extended attributes, but still everyone will keep using files
as if fopen() is the only means of finding information about a file...)


>> 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.

Directories.Start_Search is not about files, I think.
It is about file names (of certain directory entries).


Georg