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: a07f3367d7,31af760e939556ef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Interpretation of extensions different from Unix/Linux? Date: Fri, 14 Aug 2009 00:19:39 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@a26g2000yqn.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1250227250 2986 69.95.181.76 (14 Aug 2009 05:20:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 14 Aug 2009 05:20:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:7756 Date: 2009-08-14T00:19:39-05:00 List-Id: "vlc" wrote in message news:8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@a26g2000yqn.googlegroups.com... ... >If the specifications are different, the utilities in Ada.Directories >are quite unusable for UNIX/Linux. I think you are seriously confused about how this stuff works in Unix. (Either that, or I'm getting senile... ;-) > In case I want to process all *.c files in a given directory, I could code > something like > >with Ada.Directories; use Ada.Directories; > >procedure Parse is > procedure Do_It (Directory_Entry : Directory_Entry_Type) is > begin > -- Do something > end Do_It; >begin > Ada.Directories.Search (".", "*.c", (others => True), Do_It'Access); >end Parse; > >If I want to ensure me what files will be processed, I would call e.g. > >ls -A *.c > >first. But if there would be a file ".c" in the current directory, it >would not be listed by the "ls" command, but processed by my program. But "ls" does not display all of the files by default! You need an option (I don't recall which one; I used to always use "ls -al" but I no longer remember why) to see the files that start with a ".". That doesn't mean that they don't match the wildcard, it just means that "ls" doesn't display them. If you did an "ls *.", that wouldn't display ".", either, but there still is a file with that name in the directory. Ada.Directories.Search does "display" all filenames, of course, as there is no filter to match the goofy behavior of "ls". So you see this file that "ls" does not show. My recollection (mostly from the CSH on Unix, SCO, and Sun OS, which admittedly is a long time ago) is that this is a feature of "ls" only. That is, if you write your own program "wobble" and then call it wobble *.c you would in fact get the file ".c" in the list of files passed. After all, "*.c" is just a regular expression, and one that clearly matches the string ".c" (since '*' means match 0 or more arbitrary characters). If that's not true, then the implementation in question probably has a bug (it really ought to match what the shell does, although there can be no *requirement* of that). But I suspect the problem here is that you are confusing the partial list of files that "ls" displays by default with the meaning of wildcard file expressions. Randy. P.S. I recall that I programmed my csh to include a number of options on all calls to "ls" (and a number of the other predefined utilities) so that I didn't have to type them all the time. Which may be why I don't remember which ones they were...