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> <545bgvF1ttrphU1@mid.individual.net> <1495406.QZvfpqijrQ@linux1.krischik.com> <6dy7mn3hhu.fsf@hod.lan.m-e-leypold.de> <1172328891.5496.62.camel@localhost.localdomain> <1173096982.3712.37.camel@localhost> <8utzwzzv0v.fsf@hod.lan.m-e-leypold.de> <1173185771.11841.69.camel@localhost> <11wk29zr0.fsf@hod.lan.m-e-leypold.de> <1173305192.29628.82.camel@localhost> <1173447204.5618.131.camel@localhost.localdomain> <8g649apcio.fsf@hod.lan.m-e-leypold.de> From: Markus E Leypold Organization: N/A Date: Mon, 12 Mar 2007 16:17:17 +0100 Message-ID: <3yr6rulcea.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:eOi6+ojkMeycSEiHNW1iZ+xGD2k= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.207.76 X-Trace: news.arcor-ip.de 1173712256 88.72.207.76 (12 Mar 2007 16:10:56 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:14481 Date: 2007-03-12T16:17:17+01:00 List-Id: Jacob Sparre Andersen writes: > Markus E Leypold wrote: > >> A running Ocaml toplevel requires only slightly more meory than bash >> and it is faster and needs to fork less external tools. > > In my view, the whole idea with a shell is that it is used to launch > (fork) external tools, so I am not convinced that it is a real > benefit. Yes + no. The shell is an environment where "procedures" are implemented by providing external tools / binaries and composing them via pipe. This was the best way to handle things on s PDP/11 with really tight memory constraints. These days it's perhaps better to "internalize" many of the standard functions. My suggestion is, that a "tool" actually corresponds to a function (stdin -> stdout :-) and piping is actually function composition. Of course external tools are a separate case now, but that can be handled by introducing a wrapper: do-something | run "foo" ["arg1";"arg2"] | do-something-with-output Running multiple external process connected by pipelines becomes less important now and will be a seperate case. Regards -- Markus