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 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> From: Markus E Leypold Organization: N/A Date: Tue, 06 Mar 2007 16:07:47 +0100 Message-ID: <11wk29zr0.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:o9OeVdbBYsLgaEngyizdb20BbY0= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.208.61 X-Trace: news.arcor-ip.de 1173193300 88.72.208.61 (6 Mar 2007 16:01:40 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9755 Date: 2007-03-06T16:07:47+01:00 List-Id: Georg Bauhaus writes: > 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. Fine. 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). The limitation of the length of the command line passed to a process on the other side is a Unix thingy, though I think you're all overrating the impact, following the red herring of wild cards. Unix _also_ supports the VMS-like model of calling to a procedure which delivers input items one by one: It's called pipe, and modern shells support passing lists of files by pipe, using rather universal criteria, with something called process substitution: tar -T <$(find . -mtime +3 -type f) -cf foo.tgz should archive all files that are older than 3 days. As far as the shell syntax is concerned: - There are shells that are based on established programming languages (ipython, scheme shell) - I do think the VMS shell has the same problem with the difference between foo yadda*.* and foo yadda *.* - I do see user complaining about having to type quotes all the time. - Piping untyped text between processes and having untyped files is certainly to some extend one of the _features_ of Unix. It is thinkable to replace the Bourne shell by a modern byte code based shell and most of the tools by dynamically loaded libraries. In this case there would be a difference between piping between processes and command composition and typing can be introduced. > 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? Yes, but the brokenness of the auto configuration philosophy has nothing to do with Unix design choices. It is actually a problem VMS wouldn't have, since it doesn't exist in different sizes on vastly different platforms. > 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. > Will REXX programs > look the same? The same as what? > 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? And would I want to have a command prompt with the verbosity of Ada? > think. But damn right? Yes. > 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. > This might have had other consequences somewhere else. Instead, it > was to produce the pattern itself--which is very different from a > file name. ... but adds a bit of more convencience for interactive use. You shell scripts should either quote or use the appropriate setting. > echo(1) is a highly overloaded function, so to speak, very flexible. ? It only ever does echo its arguments to standard output. Only 'true' and 'false' are simpler. > So flexible indeed that it takes some time to learn how this one > command interacts with all sort of things Unix. I repeat: What you learn here is not about echo(1), but about the way the shell handles the production of arguments before executing a process. A short (or longer) look into shell manual will clarify all these things once and for all, for all "shell commands". > That's unlike what ls produces. I already explained all this. You're again attributing something to a "difference" between 'ls' and 'echo' that simply doesn't exist, at least regarding the handling of arguments. > 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? Not doing wildcard expansion at all. Certainly. > I wouldn't mind programs that just read their arguments unexpanded I would mind it, since I want syntax to refer to groups of files. And BTW: Unix tools don't "read their arguments expanded". They often don't expand arguments at all, instead it the shell, that provides ... and if you don't want ... just turn it off ... or ... quote. You know the text already, I've written it for a number of time now. > 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 "*". Please, Georg, read and try to understand what I'm writing. Most of what you complain about are features that CAN be turned of by at most 4 lines in your login script. You can also just use another shell. > 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. For a shell? Better even: typed files? Push XML to the file system? No -- that's not the way to go. I agree, a bit more of typing would be a nice thing: Extended attributes that would deliver typing hints to processing programs and a common system of shared libraries that somehow represent readers and writers for certain types / representations. That would be really useful. > > Or with this change, if calls to the expansion service should not > be part of Unix programs, why not have > > $ ls $(expand "*.ads") Process substitution would provide this, if 'ls' had a 'read from this file parameter. You can achieve exactly this effect by writing (lf => list files): lf(){ F="$1"; shift; xargs <"$F" ls ; } and then lf <(find /etc -type f -name 'fs*' ) As it is, until now it probably wasn't important enough to most people who could well live with find /etc -type f -name 'fs*' | xargs ls > 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. Process substitution, though, works with large directories. And the suggested metgod of expansion is more flexible, since it can select after modification date etc. > (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 Today? The last time I saw a basic, standardized Unix environment was V7. You must have missed out on all that Apollo Domain stuff, the Munix system (Cadmus) etc. > 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. It is arguable bad pratice to have all that on by default, but on the other side, this is hardly a "Unix design choice". The distributions I use, don't have it on and as an admin I always let it stay an option and tell my users just to source 'init.completion' or 'init.gnu-pack-2' something like that in their setup. > Unix used to be configurable (after mastering the design > choices). Now it is pre-configured... Is it? My Debian system sets the path in /etc/profile and a default umask. The rest is under my control. > I guess the consequence is that many users think they won't need to > learn shell programming. Well -- hardly anyone nows shell programming any more, I've notice. Even people who call themselves hackers and developers ... > For large jobs, ed(1) is the most efficient editor If used with the following compatibility command: $ ed ! emacs Regards -- Markus