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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e219d94b946dfc26 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!feed.xsnews.nl!border-1.ams.xsnews.nl!feeder1.cambrium.nl!feed.tweaknews.nl!news.netcologne.de!nhp.netcologne.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Command_Line and wildcards Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <45dcaed8_6@news.bluewin.ch> <1172132169.423514.271890@s48g2000cws.googlegroups.com> <87hctei5pf.fsf@ludovic-brenta.org> Date: Fri, 23 Feb 2007 09:43:35 +0100 Message-ID: <1mfuswgpg7jnw.1n6gsbbh4zv7u.dlg@40tude.net> NNTP-Posting-Date: 23 Feb 2007 09:43:36 CET NNTP-Posting-Host: c04358eb.newsspool4.arcor-online.net X-Trace: DXC=PC0E=LjnYA6Tia]Ho99G504IUKDNcfSJ;bb[5FCTGGVUmh?4LK[5LiR>kg2dOB^dZi52S: X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:9446 Date: 2007-02-23T09:43:36+01:00 List-Id: On Thu, 22 Feb 2007 20:38:37 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On Thu, 22 Feb 2007 19:26:56 +0100, Markus E Leypold wrote: > >>> The unix philosophy of handling the passing of command line >>> parameters to the programs is, I think, time tested, >> >> Really? How does this philosophy apply to modern software? Let's >> take internet browser, compiler IDE, office tools, database as >> typical examples... > > If they take command line parameters to launch -- and many of them do > -- they will at that point behave like any other command line > program. And after that their behaviour is surely irrelevant to > this discussion? Isn't it the behavior which is supposed to be controlled by the command line? What else is the command line "philosophy" for? (Obviously, any more or less complex behavior cannot be controlled by this way. Secondly, that little what could, still does not fit into the pattern of shell's parsing.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de