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: g2news2.google.com!news1.google.com!news2.google.com!news.germany.com!news.belwue.de!newsfeed.arcor.de!newsspool2.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: <11wk29zr0.fsf@hod.lan.m-e-leypold.de> 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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-ID: <1173305192.29628.82.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Wed, 07 Mar 2007 23:06:32 +0100 Organization: Arcor NNTP-Posting-Date: 07 Mar 2007 23:03:18 CET NNTP-Posting-Host: e4360091.newsspool2.arcor-online.net X-Trace: DXC=V=\Ml 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 tools. For me, this counts as part of the design of Unix. > modern shells > support Yes, it is a good thing that modern shells support... , and I find reading tar names from pipes a natural extension. (Anyone using cpio, besides comeaucomputing.com? ;-) Incidentally, in a more limited environment like DOS, programs tended to have an @-parameter for reading things from a file. Simple, but parameterizing a program then is more like assignment to temporary variables instead of using elegant functional pipes. And there is no garbage collection, the @-files are still there when the program has finished :-) > > 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 > langauge. 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. 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. > > Will REXX programs > > look the same? > > The same as what? The same as the expressions above. > > 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.). Unix operators write. Unix shell program authors write. 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 writer? (Of course, if your audience consist of readers who read nothing but "Unix stuff" they will be well served with just abbreviations.) > > 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. 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. > 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. > 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 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.) > 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? > 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. (And DOS, too.) I'm a Unix user by choice. But I can't modify every Unix system I have to use on a daily basis.