From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6bf1c4b845bd2160 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!news.unit0.net!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 24 Aug 2010 19:10:14 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: What about a glob standard method in Ada.Command_Line ? References: <4c6f9837$0$5420$ba4acef3@reader.news.orange.fr> <4c739e76$0$6992$9b4e6d93@newsspool4.arcor-online.net> <152a2z5en4z2o$.xjsuqr7s8yak$.dlg@40tude.net> <4c73e859$0$6991$9b4e6d93@newsspool4.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4c73fcf6$0$6992$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 24 Aug 2010 19:10:14 CEST NNTP-Posting-Host: 28cdb734.newsspool4.arcor-online.net X-Trace: DXC=XS=:34RAVQX@@RW1FjIB5S4IUKZLh>_cHTX3j]0DIFM1@BZ>] X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:13706 Date: 2010-08-24T19:10:14+02:00 List-Id: 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