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 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> From: Markus E Leypold Organization: N/A Date: Thu, 08 Mar 2007 10:16:07 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:p1cFpMM8sj6rnDi6xw7GpycPgU4= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 88.72.203.69 X-Trace: news.arcor-ip.de 1173344995 88.72.203.69 (8 Mar 2007 10:09:55 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!news.glorb.com!ecngs!feeder.ecngs.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:14430 Date: 2007-03-08T10:16:07+01:00 List-Id: 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. And since I already recommended some other shells (that have a more regular syntax) that should have been clear enough. > tools. For me, this counts as part of the design of Unix. But the syntax of the shell has nothing to do with a design choice "of Unix". It is not fixed. (This argument tires me -- have you even tried to understand what I wrote before?) >> modern shells >> support > > Yes, it is a good thing that modern shells support... , > and I find reading tar names from pipes a natural extension. So? That interesting does not count as a positive point with Unix for you, whereas the syntax of a shell built for a 16-bit processor (the pdp/11) and kept out of tradition counts against Unix, despite the fact that it is not an immutable part of the design? <...> >> > What is the reason that the Unix design choices do not help prevent >> > complex, strongly coupled, highly dependent pieces of shell >> > programming? >> >> Neither does Ada: You can write strongly coupled amorphous code in any >> language. And the shell is, I repeat, no programming language, but a >> command language. > > I disagree. The Unix shells are programmable, this is one of > the things that made them different. So there is programming > going on. Your choice. Don't complain to me if you use the wrong tools. Other people have switched to perl or python for things like this (cron jobs). > It's fun, I spent almost half the day preparing a > cron job, enjoying varname=${1:-$(date +%Y-%m-%d)} and such. > Sparingly though, as others in the shop might want to read > this shell script. 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 __________. Thanks. >> > Will REXX programs >> > look the same? >> >> The same as what? > > The same as the expressions above. And? Will they? Probably not. REXX had another syntax AFAIR. BTW even C programs, Python, FORTRAN and Plankalk�l will not look the same. What does that tell us? And yes I'm deliberately obtuse now, since you alway just hint on something offering spurious anecdotal evidence but than fail to spell out your complete reasoning (which usually cannot be completed due to the spuriousness of the anecdote that is supposed to show something). >> > Unlike Ada, Unix favors the *writer* over the reader. No surprise I >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> I cannot follow your argument here. Ada is a programming language, >> Unix is an operating system. Are you comparing apples with oranges? > > No. When I mean Unix design choices, I mean Unix as it was planned, > granted, and sold (with troff, sh, etc.). Fine. So you're still comparing apples with oranges. > Unix operators write. > Unix shell program authors write. Yes, *Unix shell* programmers write. You know, a drivers license is somewhat different from a driver, etc. You're a German, but probably not Germany (notwithstanding bad image campaigns). "Unix shell" is something to be distinguished from Unix. Care to rephrase your statement that I can see what you mean? > Programmers can use (I hope) some > shell programming to create software configurations. But considering > names like "creat" (sic) and the like, traditional short option letters, > etc., I fail to see how typical Unix abbreviations aren't favoring the Hm. 'creat' is not in my shell manual. > writer? (Of course, if your audience consist of readers who read nothing > but "Unix stuff" they will be well served with just abbreviations.) - cacls folder /e /r user - @DUA2:[...] And don't force me to quote from the VMS source code. Or perhaps all operating systems have bad design choices? Why then are you specifically shooting against Unix? >> > When it comes to echo *.ads, a decision was necessary as to what >> > should happen when there is no matching file name. >> >> > The choice was >> > not: reflect this fact and produce the empty result. >> >> The choice was to make it user settable. I've already quoted the >> relevant flag elsewhere. > No, I mean the use case perspective that Hyman has mentioned. Which was that? I don't think I want to read back through the thread to interpret this reference. > You can run the ls(1) program without argument, and it produces > results that make sense in most cases. Case distinctions come > into play later. NO, bloody no. Just turn wildcard expansion off _completely_ AND/OR turn of that the expansion of a non-matching pattern is the pattern itself. IT IS USER SETTABLE. Just do it. Case distinctions? What? I don't even know what you're talking about here. But I'm certain, I'm missing some finely spun argument here which would demonstrate that the fact that the users cannot be bothered to understand their tools and cannot be bothered to change setting -- how that suddenly becomes the general and deep fault of the Unix design choices again. Well -- as far as I'm concerned, you can look for hairs in your soup as long and as hard as you want. I, simply, find it more productive to understand stuff and see how I can work with it, instead of waisting energy to should-have-beens and cant-have-it-like-that where I simply have no way to force a change now. I've other and better wind mills to fight. I'm certainly not saying that Unix is perfect. There is quite a lot of things I'd improve if I could. But the things you complain about a certainly either not problems at all and certainly not important. >> A short (or longer) look into shell manual will clarify all >> these things once and for all, for all "shell commands". > Every longer look into a Unix subject might clarify. However, the > question is whether there should be a need for that much > clarification in the first place. That's the point. "That much" is a rather vague criterion. Again we're back to wether a user/programmer can be bother to learn his tools. BTW: "Concerning Ada: (Almost) every issue with Ada the ARM might clarified by a look into the ARM or into Barnes excellent book. However, the question is whether there should be a need for that much clarification in the first place. That's the point". Do you see NOW how utterly empty such statement are? >> You're again attributing something to a >> "difference" between 'ls' and 'echo' that simply doesn't exist, at >> least regarding the handling of arguments. >>>From the use case perspective there is a difference between echo > and ls. Why is it better when a user has to learn one or two levels of He has not. Just turn wildcard expansion off. The feature there for exactly that purpose. > indirection only in order to understand how Unix programs interact with > Unix shell expansion rules? > Sounds like: This car has four pedals. > You will drive better when you learn how to use them. Please note that > when this car was designed, most other cars needed two operators, and > they didn't have pedals at all! (Comparing JCL, say.) More bad mataphors. Always a good way to drag out a discussion until kingdom come. What you require, is, that the car doesn't have any pedals and that the user does not have to understand that a non-running car is sometimes to be fixed by filling in gasoline, but sometimes by turning on ignition. >> And BTW: Unix tools don't "read their arguments expanded". > > I mean after expansion has taken place (or not), > $ strace ls *.pl 2>&1 |head -1 > > execve("/bin/ls", ["ls", "check.pl", "test_md.pl", "test.pl"], ... > > After expansion has taken place, there is something in argv > that I'm calling expanded arguments. No? No. _Unix tools_ still don't "read arguments epxanded". The _shell_ provides an optional language to _generate_ arguments. The _Unix tools_ have nothing to do with it. >> Please, Georg, read and try to understand what I'm writing. Most of >> what you complain about are features that CAN be turned of > > The Unix design choices can't be turned off. ls(1) has a default > behaviour. That's Unix. But you DIDN'T complain about the ls behaviour. You DID complain about the shell expansion, that CAN be turned off. You're completely mixing things up. Does it even make sense to continue this "discussion"? >(And DOS, too.) I'm a Unix user by choice. Who has such friends doesn't need enemies. > But I can't modify every Unix system I have to use on a daily basis. .profile, .bash_profile. cvs. Yes, you can. And if you don't have a single system image or a deployment mechanism for configurations on disjoint systems that again is not a Unix design choice, but perhaps a choice of your system administration / administrators. Regards -- Markus