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 Path: g2news1.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.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Ada.Command_Line and wildcards From: Georg Bauhaus In-Reply-To: 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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1173447204.5618.131.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Date: Fri, 09 Mar 2007 14:33:25 +0100 NNTP-Posting-Date: 09 Mar 2007 14:32:23 CET NNTP-Posting-Host: a7499936.newsspool3.arcor-online.net X-Trace: DXC=>4;GG`Gk9P`PKPPVf;4hUjMcF=Q^Z^V3h4Fo<]lROoRaFl8W>\BH3YbG]f>Z2[06EhA:ho7QcPOVcnT;LmDLnbOf8LY6L92Z[]e X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14431 Date: 2007-03-09T14:32:23+01:00 List-Id: On Thu, 2007-03-08 at 10:16 +0100, Markus E Leypold wrote: > Georg Bauhaus writes: > > > On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote: > >> Again let me differentiate that the syntax has nothing to do > >> with Unix design choices, that is "only" a shell thing and the shell > >> can be replaced (already has more than once). > > > > Well, I find it difficult to imagine Unix without the > > programmable shells, intended to be used as glue between the > > Aaaargh!! Did I say that? No, no, no! I said "replaced", not > abandoned. I don't argue against using Unix, and not against configuring Unix work environments either. The whole thread is about the consequences of some longstanding Unix design choices which then established what can know be termed the Unix design. Text substitution is still part of every successor design. I really do know how to melt and loosen Unix design choices and replace these choices with things I need today, on my machine. *BUT*: (1) Textual substitution as in the original Unix design keeps having consequences today, with or without new shells, with or without pattern expansion. This is just a fact of life with Unix, by design. (2) Omissible text has consequences today, by design. These are the design choices in question, see the prior postings to this thread. Suggesting replacement parts for pieces of Unix really means suggesting to change its design. It isn't turned into Windows NT by these changes, but someone coming from Unix will have to learn how to use the new parts. You keep listing perfect examples of how to improve on the Unix design, by replacing parts of the design (e.g. different shells, hence differently designed shells), new features, or by suggesting to configure environments should it be necessary to overcome default settings as per design. Fine. So the original design has its flaws. (BTW, it is part of the design of Unix that I *can* do these things. There is very little one can comfortably do in this regard using cmd.exe without extensions.) By analogy, if we were talking about why they chose to make "tagged" a keyword during the Ada 9X process and not make every type implicitly tagged, we are talking about the Ada design (choices). For the notion of Ada design, it doesn't matter that there can be Ada-like languages that have implicit tags for every type. And it doesn't matter that I can use Ada without Ada.Text_IO, or without tagged types; both are part of the Ada design, no matter what. And this has consequences and I have to know them, for good or bad. Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984). You don't have to use either Unix or Ada in their entirety; you can replace some parts, which is good. If you used an encoding aware string type in place of Standard.STRING etc, your program might be better, but you don't change the Ada design choice for String types. You only avoid the consequences of the original design. So the original design has consequences. Some parts of the original design are just irreplaceable. By turning off shell expansion, no one can change the Unix design which offers shell expansion. (I doubt it is really used as just an option in typical Unix use, but rather taken for granted.) In particular, some parts of Unix design are just hard wired, as you have demonstrated a number of times by informing us about your knowledge of the many wires (mechanisms). > Thanks for sharing that story with us. The conclusion for a more > general view on Unix is ... -- Please complete the following sentence: > > Georg B spents almost half the day preparing a cron Job. From that > we must conlude that Unix __________. I'll appreciate your view, although I trust no one will hurry to infer Unix design properties from my having fun when working with Unix. > Thanks. > What does that tell us? [REXX, scsh, etc.] It tells about alternative designs. About a way to compare design choices by their consequences. About what can be done when it comes to successor designs. > But I'm certain, I'm missing some finely spun argument here Yes. I think you are missing the argument of this thread. That the parts that make up Unix, with Bourne shell and C shell and expansions, could have been designed differently in the past WRT how to use textual substitution and WRT the amount of omissible text. Much like "creat" (without the final letter 'e') could have been named differently, as told by its creator. Or should I accept that the Unix design was flawless in the first place, and that programmers should just have learned to omit the final letter from the word "create"? I think this example is representative of some Unixisms. They are fun, but not to be repeated as designed. > Again we're back to wether a > user/programmer can be bother to learn his tools. We are back to whether a design choice makes using a system more or less work. Whether it has more pitfalls, requires more or less configuration, more or less training to achieve the same level of productivity, etc.. (BTW, are you saying that the expression argv[1] is not used when reading arguments from the command line?)