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.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD 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 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> From: Markus E Leypold Organization: N/A Date: Fri, 09 Mar 2007 18:11:59 +0100 Message-ID: <8g649apcio.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:a7AJO9l58547StJ1SQNCCQTGaOQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.201.211 X-Trace: news.arcor-ip.de 1173459945 88.72.201.211 (9 Mar 2007 18:05:45 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.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:14433 Date: 2007-03-09T18:11:59+01:00 List-Id: Georg Bauhaus writes: > 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. If you mean by "text substitution" evaluating arguments and passing them to procedures / tools, then you're right: THis is something I don't want to miss. If you really mean text substitution, neither the scheme shell nor i.e. iphyton are based on text substitution. They are based on proper programming languages with properly delimited strings and functions. > > I really do know how to melt and loosen Unix design choices > and replace these choices with things I need today, on my machine. Good ... > *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. I admit that, but I find your use of "Unix" still problematic here. First, the kernel itself doesn't know ynthiong about text substitution. Second, text substitution is something implemented in a lot of Unix tools (cpp, m4, sed, awk) and it is often exactly what one needs to process text. The feature has ben misused in the past, but that is not restricted to Unix: We find wild pattern matching on input (insterad of proper parsing) and "template expansion" (an euphemism for text substitution :-)) all over the place. XML is also based on text -- with all the consequences this has. > (2) Omissible text has consequences today, by design. I don't quite grok what you mean by "ommissible" here. If you mean that quoting is not obligatory -- yes, that is the hallmark of many interactive command languages, a number of them not grown on Unix at all. It's the spirit of the 70s ... ;-). And BTW: I'm not sure they were wrong. I wouldn't want to use Ada as an interactive command language. There are, I think, ways to get (1) type safety, (2) proper quoting without too much overhead. I, personally, would built a new generation shell system on, ahem, OCaml, because of the type interference and because functional composition might take the part pipes have played in the past. Something like dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) | flatten | print dir_entry_long should be possible. > 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. No. I do think you use the word design in rather too broad a sense. Else we could never change ynthing without "changing the design". One must perhaps live with the notion that no OS is just amonolithic complex of design choices. It is not simply a "design change" if I (user) change to another shell (that is designed to be user replacable, BTW). The syscall API doesn't change. The compilers don't change. The configuration system doesn't change. The libraries don't change. Of course you can lump all in one and ignore that a system like Unix is built up of layers. But then I think you're missing something. At least the chance to understand Unix better and learn to live with it. The decision to have text substitution in the default shell, doesn't permeate Unix. Most of the parts of Unix a blissfully ignorant of that and that is good as it is, since that means we can have an embedded Unix with e.g. busybox as shell, which does not do all the fancy stuff bash does -- and we can still install/use/integrate basically the saem tool set. So no -- e.g. text subtitution is no "Unix design choice". > 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. Well, that is the nice thing with Unix: Many of those "you have to learn to use a new thingy" are quite optional. Shells are per user configurable. The use of specific programming languages can be decided per project and so on. You never need. You can. > 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. Of course if I didn't want to use Bliss at VMS, I always had the choice to use Pascal. Does that indicate a "design flaw" in VMS (they never should have had Bliss at all)? Hardly. > (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.) Exactly. So you continue to brand chances as proofs of flaws. Bad, in my opinion. If you don't like the shell, use another. If you don't like a programming language (shell, C), use another (Python, Ada, ...). Thousands of programmers never had problems with old shell or the existing languages. That you have a problem with them doesn't make them (a) design choices or (b) bad design choices. They weren't wrong to be there in the beginning (in the 70s there WAS no alterntive design nor a resonably priced machine that could carry it), that they are still here today is also no design flaw (but compatibility, pure and simple). BTW, I not, we're back to one of the old C vs. Ada themes: Why don't people _change_ to other languages etc. -- Well, as I have already alborated often enough, there are reasons. That bourne shell (and C) are still there doesn't make them bad design choices for the very reason that _you_ as user and developer have the choice not to use them, but still use Unix. > By analogy, if we were talking about why they chose to make "tagged" No analogies please. They are like a green potato thrown after a running dog and don't scratch the mustard. "Hngh?" you say? You see, exactly that: Analogies are pretty bad to discuss somethingm because they are often difficult to understand, their validity is limited and needs to be subject of another discussion (as if we hadn't enough of that already). > 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. Well, see. Again you're using a programming language as an analogy for an operating system. Instead of talking about first principles to built OSses and how to best structure user interaction with the OS. That does bring us nowhere. > Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984). ?? entire things ?? > 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. More (bad) analogies ... :-( > By turning off shell expansion, no one can change the Unix design > which offers shell expansion. Aaah, I understand: Its bad to offer functionality, even to those users that want it? > (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). 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. If you want to know how much functionality in Unix is really hard wired, I suggest you study some of the development and porting history of Bell Unix. There hardly seems anything that was no expendable at one time or other (from users to full fork/exec). >> 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. It is good that you see that. So we're actually back to square 1: (a) A number of anectodes "things I found surprising when working with Unix" (or should that be "thing I pretend to have found surprising", since you always insist that you know very well how all that works, only you think that other ) and (b) a number of assertions that Unix is badly designed in some (IMHO minor) points that are not connected to (a). The problem as I see it, is basically, that we're discussing straw man: Since you insist you can work with it and it is not really your problem, we can only talk about problems of others. Or about problems of the industry in general. That would require either something more than narratives about your experiences (you don't have a problem, rembember) or trying to establish sonme first principles on operating system design and then relate the Unix design to that (I don't think we'll be able to lead that discussion). >> Thanks. > > > >> What does that tell us? > > [REXX, scsh, etc.] It tells about alternative designs. About a way REXX ahs never talked to me. As far as "seeing" things goes, I can agree that REXX, C, Python, Ocaml, Bourne shell and Perl programs are all different. Their beauty or ugliness and their relative merits though all lie in the eye of the beholder. Since the programs don't talk to me, a bit more reasoning would be required to establish some conclusions here. > to compare design choices by their consequences. About what can be > done when it comes to successor designs. Since I'm not able to deduce the existence of chocolade pudding and income tax from "cogito ergo sum", abit help would be required to point all those conclusion out to me. But before you do that, perhaps it would be useful to formulate a hypothesis / lemme that relates to out Unix discussion and woul actually change the course of our argument and only after we have indeed established that, try to somehow corroborate that hypothesis / argument with conlusion drawn from the evolution of REXX. I doubt that is possible, except in very general and useless sense, since REXX is a language, Unix an OS and you'd probably also say something about the validity of transfering conlusion from one domain to the other. > >> 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. Good. Should haves are indeed not my bailiwick. How to change things to the better are more in my direction. Rant on against the shell, if you like. The shell (I say it again) is not Unix, a formulation youd use again and again. > Much like "creat" (without the final letter 'e') could have been > named differently, as told by its creator. Still, creat is not in my shell manual. The topic is still shell related isn't it? > Or should I accept that the Unix design was flawless in the > first place, Admitting that Unix certainly has flaws is quite different from admitting to your specific points. Probably "X has some flaws" is true fro any man made X. > 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. What nonsense. You undertand the words "history artefacts". Is DUA0 named DUA0 because it is perfectly understandable or for some deep design choice or because of historic development? >> 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 Aaah! So the VMS shell is just so much less work than the Bourne shell? I had the impression that most of the additions to the shell in V7 had the purpose to save work (also to the tool writers). > less configuration, more or less training to achieve the same > level of productivity, etc.. I'm sure you can prove that Unix fails miserably in all that? Esp. if compared to better or newer operating systems? But let's not start that discussion again. If you just want to _state_ how much more complicated _you_ find the Unix shell and working with Unix (than ...?), we can just leave it at that. It's hard to contradict testimonies of personal experiences that properly start with "I". It's only conclusions we can dispute. > (BTW, are you saying that the expression argv[1] is not used when > reading arguments from the command line?) Yes it is used. But I do not understand the drift of your argument. Using argv[1] does not expand the argument, does not relate to quoting or the shell. It's outside of the scope of the world view tools have: They get arguments and they process them. Some of them even expand them (mcopy, e.g. or find) others use them as they find them. That is, indeed, exactly as it is in VMS (we've been refereing to VMS a number of times as a counter example). But in the sentence "the tool reads the expanded arguments and they do it wrong" there is either a hidden actor somewhere inplied (the shell) and that means "they do it wrong" can't mean the tools, but should refer to the shell OR the expanded is somwhat out of place: "the tools read the arguments. Fullstop". But you snipped that part of my last post, so maybe I'm relating you question to the wrong subtopic. Summary: Yes, argv[n] (0<=n<=argc) is used to retrieve the command line words. But how is that related to the discussion on the Unix shell? Regards -- Markus