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,e219d94b946dfc26 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Ada.Command_Line and wildcards References: <45dcaed8_6@news.bluewin.ch> <1172132169.423514.271890@s48g2000cws.googlegroups.com> <1172257457.802242.307050@j27g2000cwj.googlegroups.com> <1172259022.144832.81680@8g2000cwh.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Fri, 23 Feb 2007 21:07:42 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:sZsg/23Es6FWMVOppU8DuC1bknw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.213.115 X-Trace: news.arcor-ip.de 1172260918 88.72.213.115 (23 Feb 2007 21:01:58 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9480 Date: 2007-02-23T21:07:42+01:00 List-Id: "Adam Beneschan" writes: > On Feb 23, 11:04 am, "Hyman Rosen" wrote: >> On Feb 22, 8:15 pm, Robert A Duff >> wrote: >> >> > Yuck -- bad design! >> >> The designers of UNIX didn't feel that it was necessary for every >> program to incorporate a wildcard expander when that could be done >> externally. Back then keeping programs small and simple was a virtue. >> >> > And there's no wildcard that means "all subdirectories, recursively". >> >> And no wildcard that means "all files that have changed since >> yesterday". >> >> There are an infinite number of things that you might want to specify. >> Many of them won't have been thought of when the programs which could >> benefit from them are written. That's why it's better to do these >> things >> externally, and just have one program to modify when you come up with >> your new wildcards. > > But as has been said several times before, the OS could have provided > a service that could have been called iteratively to return the file > names, one at a time. Well, it does. It's called 'find' and pipe like this: find dir1 dir2 -name '*.ada' -size -5000 | command_that_reads_its_files_from_stdarg It depends on the tool wether it supports reading its arguments from stdin. You can always roll your own by providing an appropriate shell script wrapper if it doesn't. And if everything fails: Nobody _forbids_ your tool to expand the command line arguments on its own. > That's how VMS does it. So? > This arrangement would solve both the problems you mention > above---keeping the applications small and simple, and allowing for > new types of wildcards without having to change the application. See the solution with find and the option(s) to pass arguments and lists in temporary files. Regards -- Markus