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!t-online.de!feeder.news-service.com!proxad.net!proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sat, 10 Mar 2007 16:48:53 +0100 From: Georg Bauhaus User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 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> In-Reply-To: <8g649apcio.fsf@hod.lan.m-e-leypold.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <45f2e13b$0$15952$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 10 Mar 2007 17:47:55 CET NNTP-Posting-Host: 166ab981.newsspool4.arcor-online.net X-Trace: DXC=VM6LN72n;ieJ00P1S40fZg4IUK Markus E Leypold wrote: > I find your use of "Unix" still problematic > here. I thought it is quite common to think of Unix as kernel, hierarchical filing system, pipes, utilities, shell glue, compilers, job control, text processing, ... and then speak of the whole collection as Unix. >> (2) Omissible text has consequences today, by design. > > I don't quite grok what you mean by "ommissible" here. Arguments may be omitted, quotes may be omitted, basically anything can be omitted whose description includes a phrase that starts, "if there is no x, then y will ...". See below. >> 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). This was written in a mood. Read, "when explaining the many wires (mechanisms)." > > My bad. I shouldn't have given the impression to know anything about > Unix (soft wired knowledge). > > So if I know about something well enough it must be _hard_ wired? Get > real, Georg. Let me concentrate on a few things hard wired into Unix(TM). Let me exclude descriptions of operating environments that are based on parts of Unix and on other things, because these operating environments cannot illustrate Unix design decisions where Unix, as above, refers to what you would have got buying Unix. (I think that few have a problem with the inclusive notion of Unix when speaking about the design of the OS made then?) So, leaving out options handling for the moment, in Unix I expect the system programs, most relevant to any shell work, to have certain behavior, by design. - echo prints its arguments. - ls stats its arguments. - Default shells may expand file name patterns. When they do, and there is no match, the pattern expansion (re-)produces the pattern. - echo without arguments will likely print an empty line - ls without arguments will list the files in the current directory. - When pattern expansion (re-)produces a pattern, echo will print the pattern and succeed, ls will stat the pattern and fail. That is, with the above choices, you can run programs, omit arguments, and get implicit default behavior. This is by design. Learning the defaults, settings, and implications will be the protective measure against some surprises. Here is another set of choices. They stubbornly disallow no-argument calls, doing exactly what Unix rm(1) does, in this regard. - echo prints arguments - ls stats arguments - Default shells have no notion of file name pattern expansion. - fnexpand(1) expands file name patterns. When there is no match, it produces nothing. Otherwise it prints all matching filenames, properly quoted. - echo without arguments will fail - ls without arguments will fail So we might have: $ echo $(fnexpand "*.ads") echo: no arguments $ ls $(fnexpand "*.ads") ls: no filenames $ Either set of choices has consequences. One consequence is that one source of surprises is excluded by the second set, by design: If there is no argument, a program will fail. This is opposed to what we now have in Unix as designed: If there is no argument, whether or not the program will fail depends on the program Therefore, the second set of choices suggest that there might have been a different Unix design, one that permits writing shell programs and commands that would have offered simpler, more regular, easy to predict behavior at the cost of slightly more typing. (I know it is certainly possible to construct functions and programs to work like that using Unix as is. But the result will differ from Unix design.) [creat] > What nonsense. You undertand the words "history artefacts". Yes. Unix artefacts is what we are talking about. Their cons and their pros. (I must once again stress that of course there are pros, not because I think there are pros, but because e.g. Unix shells can be compared to the OS-control solutions that are/were offered by the competition. The solutions can be compared by considering use cases, and by considering technical properties.)