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

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

On Wed, 25 Aug 2010 20:44:17 +0200, Georg Bauhaus wrote:

> On 25.08.10 18:46, Dmitry A. Kazakov wrote:
> 
>>> It is not actually possible to provide a common abstraction
>>> for *new* and *existing* file names.  While "broken", the file
>>> names do exist.  Just a few examples illustrating a variety of file
>>> naming fun:
>>>
>>> - Names created in NTFS that end in a '.'
>>>
>>> - Two names in existing ext2 directories that contain
>>>  "mutually exclusive" characters (via incompatible encoding)
>>>
>>> - Names containing characters that are special in Windows but
>>>  not in POSIX.
>>>
>>> - Names with spaces in them
>> 
>> You don't get the point. See A.13(9)
> 
> 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));
> 
> 
> There is no  "string given for the parameter [Matcher]" that "does
> not allow the identification of an external file".
> The situation is reversed: The suggested overloaded procedure
> Directories.Start_Search (or Search) will RECEIVE a name from the file
> system via the run-time system; the name of an existing file; one
> that has been identified already.
> There is no identification attempt performed by the program.
> It acts as if some implementation-defined all-inclusive wildcard
> had been passed to Ada's Directories.Start_Search, as the
> Pattern : String parameter, and then, later, some callback (Matcher
> in the alternative declaration above) checks to see whether the file
> identifying file name that it got from the system is fine.
> 
> 
>   OS -> file name -> Search -> Matcher (sees file name) -> ...
> 
> Not
> 
>   file name pattern -> Search -> !! identification
> 
> But as if
> 
>   "*" -> Search -> Match (file name pattern) -> ...

What does this have to do with legality of names with spaces?

How could it help to implement search for all files matched by a*¶?

>>> If in the real word, I/O of "broken" integer values is a
>>> reality.
>> 
>> What does this have to do with the point?
> 
> I expect file names to be read from the disk, as is, I do not
> construct them.

I don't even know what does it mean to read anything "as-is." It just does
not make any sense. How do you know if ab¶ was read as-is or as something
else? Did you use magnifying glass to inspect the hard drive to tell how is
ab¶ there?

> Whether they are broken WRT some expectation
> or not is like when a program receives a valid or usable representation
> or not from an integer location:
> 
>   V : Integer_Subtype;
>   pramga Import (Ada, V);
>   pragma Volatile (V);

So, V was read as-is?

> As you can see, this is how I consider existing names of existing
> files, too.  But I want to be able to look at the bits of V, not
> just raise an exception.

Why on earth reading file name should raise exceptions except that when the
file system is corrupt? Where did you get it? From Ada.Directories? Well it
probably should if the file is named "это вам не Latin-1". But I bet,
GNAT's implementation does not. Anyway, this is another crack among others
in Ada.Directories.

>>> Almost all WWW documents are broken by your taxonomy.
>>> Google is rich...
>> 
>> I don't understand what you are talking about.
> 
> An analogy.
> If the WWW, that is, the external environment, has valid
> HTML, it is possible to use HTML grammar to describe
> HTML. It isn't valid. But we can still try to extract meaningful
> information even from syntactically broken pages.

This has nothing to do with file names, except that here you again are
confusing encoding and the contents.

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