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!news2.google.com!news4.google.com!news.glorb.com!volia.net!news2.volia.net!newsfeed.utanet.at!newsfeed01.chello.at!newsfeed.arcor.de!newsspool4.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: <8utzwzzv0v.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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1173185771.11841.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Tue, 06 Mar 2007 13:56:12 +0100 Organization: Arcor NNTP-Posting-Date: 06 Mar 2007 13:53:07 CET NNTP-Posting-Host: dda36e3f.newsspool1.arcor-online.net X-Trace: DXC=[dmOhWf;`Yi>jlK2>IgHGdic==]BZ:afn4Fo<]lROoRaFl8W>\BH3YbkgSjK3b]M9iN[W On Mon, 2007-03-05 at 14:20 +0100, Markus E Leypold wrote: > Georg Bauhaus writes: > > > On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote: > >> >>>>> "Georg" == Georg Bauhaus writes: > >> > >> Georg> $ echo *.ads > >> > >> Get a real shell ! > > > > Sure. Point is, we had been talking about Unix design choices > > not about what I am seemingly doing (doing according to you > > and others, that is, which is not what I'm doing :). > > > Hi Georg, > > As long as your arguments are heavily based on your experience and > practice we have to talk about what you're doing or we can stop > discussing. Right, but my experience, while not based on thousand of observations of Unix users, includes some of this. Moreover, some arguments are purely technical, like the many "white space thingies" in shell programming. Or the drastic semantic consequences of minor changes in quoting-or-not-or-differently type-less text that have been mentioned a while ago. This is very much unlike Ada :-) > Most (auto-) configuration concepts are really bad hacks. They are > hardly Unix design choices. The wrong place to fix that is to change > the shell or the prcess model. Right. But don't you think that this kind of use of Unix tools must be investigated such that the Unix design choices are taken into account while doing so? What is the reason that the Unix design choices do not help prevent complex, strongly coupled, highly dependent pieces of shell programming? Will REXX programs look the same? Unlike Ada, Unix favors the *writer* over the reader. No surprise I think. But damn right? 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. This might have had other consequences somewhere else. Instead, it was to produce the pattern itself--which is very different from a file name. echo(1) is a highly overloaded function, so to speak, very flexible. So flexible indeed that it takes some time to learn how this one command interacts with all sort of things Unix. That's unlike what ls produces. But it is consistent with ls and with the other uses of echo by 1..* mental indirections. Now, what might be an alternative design choice? I wouldn't mind programs that just read their arguments unexpanded and call the OS expansion service, an iteration device for example. And if there is no matching thing, then *every* program consistently produces empty results! One difference, then, is that an ls will consistently produce nothing for no argument. This will require more typing when you want something, for example ls -d "*". I don't think any Unix programmer will see the benefits of more typing. But having gone some way through the Ada experience I think this the right thing. Or with this change, if calls to the expansion service should not be part of Unix programs, why not have $ ls $(expand "*.ads") It isn't more difficult to understand, and it doesn't work with large directories either. It requires that shell commanders say what they want, though. (I'm not a fan of large directories when we do have a hierarchical filing system, but again, who am I to suggest that a program be redesigned to use a hierarchy of directories for file storage.) > > system settings. But these seem to be the new Unix hackers' favorites. > > new Unix hacker? There was a time when you knew that logging into a Unix system (HP, BSD, etc.) would give you a very basic setup. But you could use the entire Unix Toolbox, without surprises. Reaping the benefits of some shell programming would give you a productive environment. Today, the new Unix hackers try to give you a "productive" environment by default. You may have to expect AI-driven completion, and lots of aliases, and not only will learning some Unix shell programming still be profitable, but in addition you have to learn how to bridle typical default shell setups. Unix used to be configurable (after mastering the design choices). Now it is pre-configured... I guess the consequence is that many users think they won't need to learn shell programming. -- Georg For large jobs, ed(1) is the most efficient editor