jlg@lanl.gov (Jim Giles) (01/13/91)
I changed the name because the subject is no longer about UNIX vs. MS-DOS, but about the UNIX fragment-and-pipe approach to programming. In fact, many specific MS-DOS utilities suffer in ways similar to what I'm complaining about in UNIX. Also, I still don't think this newsgroup is the right venue for this discussion. I looked back at comp.sys.misc (and remembered why I unsubscribed). That doesn't look like the place. Someone suggested alt.humor - an interesting idea, but still probably not approporiate. Any suggestions? Maybe others would think that comp.sys.misc _is_ appropriate. From article <SPOT.91Jan13002434@WOOZLE.GRAPHICS.CS.CMU.EDU>, by spot@CS.CMU.EDU (Scott Draves): > [...] > Your use of UNIX must be very different from mine (and others'), or > you are talking about programming and not interactive use. Both. But all too often programming _is_ done with pipes, etc.. > [...] > I do *not* want to write a program every time I want to search a file > for a word. [...] Quite so. In my case, well over 90% of such searches are followed by an edit of the file in the neighborhood of the found word. So - over 90% of such searches I do are from within an editor - which should have such searches built-in. Much of the rest of the time, what I want the search to do is show me something of the context of each place where the pattern matches - usually, one line isn't enough of that context (so, in this case, I often end up using the editor again). So, the remaining few times I need a grep-like functionality are to make up for the lack of such a feature in tools like ls. Here is where I make my once or twice a month use of grep. I should be able to say something like 'ls -owner jblow' and get a list of all files in the directory belonging to joe blow. I _could_ write a shell script to do this (use awk to extract the owner field from an 'ls -l' sequence, then grep for 'jblow'). What I usually end up doing, though, is writing 'ls -l | grep jblow' - which has the unfortunate habit of also listing files whos names contain 'jblow'. Using grep this way doesn't exemplify the strength of grep - it simply (almost) covers a weakness in ls. A production quality ls would have the capability to filter any of the fields of a file description in generally useful ways. For example, what about 'ls -before 1/1/90' to list all files created before Jan. first 1990? Try to do _that_ with grep. > [...] > If you are saying you would never write production code in csh using > all those utilities, then I agree. And so will (nearly?) everyone > else. That would be slow and gross. Then you agree that a version of ls which does the above should _not_ be written as a shell script? Indeed, the functionality of filtering on the creation dates would probably be easier from within a program than for a script. In any case, utilities should be written to the same standards of quality and efficiency as and other production code and, by your own statement, should not be written as scripts. Note: the use of ls as an example in this note is just that: an example. The same kind of argument could be applied to many other tools (like other system inquiry stuff: ps, who, etc.) - which should all contain built-in capabilities to filter the information they produce. I don't want to get into a long discussion about specific properties of ls like this one going on about grep. The grep utility itself I chose as a specific example of a whole class of UNIX utilities whose functionality should be contained in appropriate other programs (like dd, tr, etc.). J. Giles
rthomson@mesa.dsd.es.com (Rich Thomson) (01/13/91)
I've been reading this thread and getting more and more disgusted with Mr. Giles arguments (or lack thereof), but he did a nice job of summarizing his position for me: In article <11267@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >I'm complaining about [...] UNIX. > >Also, I still don't think this newsgroup is the right venue for this >discussion. You're right. You are complaining and it isn't the right group. Take it to alt.flame. Better yet, take it to a messy-dos based bulletin board system where people will rally around you, concur with you, and generally make you feel good. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
floyd@ims.alaska.edu (Floyd Davidson) (01/13/91)
In article <11267@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >Someone suggested >alt.humor - an interesting idea, but still probably not approporiate. Considering some of your arguments, very appropiate... But you do make some good points too, so... [...] >Both. But all too often programming _is_ done with pipes, etc.. It hardly seems correct to associate bad programming with a particular OS. At least not without backing it up with some statement about what characteristics of the OS lead to bad programming. It may or may not be true that UNIX encourages bad programming, but you are saying something to the effect that UNIX is bad because it has C compilers available for it and C uses goto's, therefore UNIX is bad. May be, but not for that reason, because it is basically true of all OS's. > >> [...] >> I do *not* want to write a program every time I want to search a file >> for a word. [...] > >Quite so. In my case, well over 90% of such searches are followed by >an edit of the file in the neighborhood of the found word. So - over >90% of such searches I do are from within an editor - which should have [...] >So, the remaining few times I need a grep-like functionality are to >make up for the lack of such a feature in tools like ls. Here is >where I make my once or twice a month use of grep. I should be able >to say something like 'ls -owner jblow' and get a list of all files >in the directory belonging to joe blow. I _could_ write a shell >script to do this (use awk to extract the owner field from an 'ls -l' >sequence, then grep for 'jblow'). What I usually end up doing, though, >is writing 'ls -l | grep jblow' - which has the unfortunate habit >of also listing files whos names contain 'jblow'. Using grep this way >doesn't exemplify the strength of grep - it simply (almost) covers >a weakness in ls. > >A production quality ls would have the capability to filter any >of the fields of a file description in generally useful ways. >For example, what about 'ls -before 1/1/90' to list all files >created before Jan. first 1990? Try to do _that_ with grep. Ooops. You just ran the wrong way for a touchdown. I think you just proved the opposite point! (And suggested that you don't really *know* UNIX all that well, ten years or not.) The advantage of UNIX is that tools are trivial to the point of doing just one basic thing. As a result each user can easily build larger tools to do *anything*. You want *everything* built in (at least everything that you would use) to every program. With UNIX you can build a command (in many different ways) to do just what you desribed above. I don't need it and don't want it. I have my own list of special tools that I built for my use, and you undoubtedly don't need and don't want even one of them. UNIX gives both of us an environment that can be customized to our particular needs. If an OS were build with your critizisms in mind one of us would be very unhappy at best, or we would have one very bloated system. UNIX is arguably somewhat bloated by just giving us every possible trivial tool. Now imagine a system where every tool has every possible trivial option! Floyd PS Why use grep for the 'ls -before 1/1/91' command. There are better ways. Try 'find'. (You may want to grep the output.) -- Floyd L. Davidson floyd@ims.alaska.edu Salcha, AK 99714 paycheck connection to Alascom, Inc. When I speak for them, one of us will be *out* of business in a hurry.
jlol@REMUS.EE.BYU.EDU (Jay Lawlor) (01/14/91)
>>>>> On 13 Jan 91 11:03:14 GMT, rthomson@mesa.dsd.es.com (Rich Thomson) said: Rich> In article <11267@lanl.gov> Rich> jlg@lanl.gov (Jim Giles) writes: >I'm complaining about [...] UNIX. > >Also, I still don't think this newsgroup is the right venue for this >discussion. Rich> You're right. You are complaining and it isn't the right group. Take Rich> it to alt.flame. Better yet, take it to a messy-dos based bulletin Rich> board system where people will rally around you, concur with you, and Rich> generally make you feel good. Exactly! Since this group is (occasionally) about architecture, and most machines that run MS-DOGS have such 'exciting' architecture, you won't find many people to rally around you in this group. Complaining about Unix here (at least saying MS-DOS is better) is kind of like driving into a truckstop and yelling, "All truckdrivers are stupid morons who can't write their own names." You're bound to get contrasting points of view.
jlg@lanl.gov (Jim Giles) (01/14/91)
From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): > [...] > The advantage of UNIX is that tools are trivial to the point of > doing just one basic thing. As a result each user can easily > build larger tools to do *anything*. [...] By this logic, ls doesn't fit the paradigm. I can (on any UNIX) do 'ls x*y' and get all the files whos names begin with x and end with y. By the paradigm you just stated, I _should_ have to do 'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized that ls should have a built-in filter on file names. My claim is that any tool which reports information summaries (like ls, ps, who, etc.) should have the built-in capability to filter on any of the categories of information that it reports. Your above statement is perhaps the single thing I object to most in "UNIX think". This seems to be a discussion of analogy, so I'll give another. Let's agree to a definition: a "commuter car" is just simple, basic transportation with good mileage, etc. - no extras. Now, what _I_ want from a computing environment is a collection of tools analogous to commuter cars (at least - I'll accept a tool that does more, but not one that does less). What "UNIX think" wants to give me is a set of components with which I must reconstruct a car every time I drive. > [...] You want *everything* built > in (at least everything that you would use) to every program. No, that's not exactly what I want. To keep to the car analogy, I don't ask for all cars to be limos with the TV, phone and bar, etc.. What I _do_ ask is that each be equipped for all aspects of its basic functionality. I don't want to get into the car and end up with "Oh damn. I forgot to install the engine this morning." Ok, so you say "build a script to put the engine in". Fine, except scripts are inefficient and the engine _really_ should have been there to begin with. So should things intimately connected with the transport function - even if not really _required_ for it (like headlights, windshield wipers, and rearview mirrors). > [...] > PS Why use grep for the 'ls -before 1/1/91' command. [...] Well actually, I was arguing _against_ the use of grep for this. grep happened to be the specific example of a general class of tools that I was speaking against. There is no other filtering tool that takes a list of lines, each containing a date field, and passes only those whose date field preceeds a specific date. > [...] There > are better ways. Try 'find'. (You may want to grep the output.) Well, 'find' _does_ have filters built-in for similar time related filtering (against the advice you have been offering for UNIX tools). I'm happy to see that you regard this as a better way. However, the 'find' filters only list files that have been accessed or modified (each a separate filter) _since_ 'n' days ago. There is no way of telling it to list the files that were last modified _before_ a given date. And, indeed, that's the other problem with 'find': I usually don't know how many days it's been since a given date (my example was 1/1/90 and not this year), at least, not off the top of my head. J. Giles Note: the paradigm of small tools and piping was an early attempt at increasing reusability of software. Recent (well, actually not so recent) development of Object Oriented Programming was directed at this same issue. Now, I have serious reservations about the appropriateness of OOP for programming production codes. But, I think an OOP command shell would solve the reuse problem in the interactive environment _much_ more efficiently and flexibly than tools and pipes do.
tom@bears.ucsb.edu (Tom Weinstein) (01/14/91)
In article <11305@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > By this logic, ls doesn't fit the paradigm. I can (on any UNIX) > do 'ls x*y' and get all the files whos names begin with x and end > with y. By the paradigm you just stated, I _should_ have to do > 'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized > that ls should have a built-in filter on file names. And you've been using UNIX for ten years? The shell does wildcard substitution, not ls. You could just as easily type 'echo x*y'. -- He is Bob...eager for fun. | Tom Weinstein tom@bears.ucsb.edu He wears a smile... Everybody run! | tweinst@polyslo.calpoly.edu
pfalstad@flower.Princeton.EDU (Paul John Falstad) (01/14/91)
In article <11305@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): >> The advantage of UNIX is that tools are trivial to the point of >> doing just one basic thing. As a result each user can easily >> build larger tools to do *anything*. [...] >By this logic, ls doesn't fit the paradigm. I can (on any UNIX) >do 'ls x*y' and get all the files whos names begin with x and end >with y. By the paradigm you just stated, I _should_ have to do >'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >that ls should have a built-in filter on file names. My claim is Wrong! This is handled by the shell. The shell provides a standard, centralized filter (the UNIX approach), instead of having every separate command do the filtering, so you have to remember which commands do the globbing and what the syntax is in each command (the MS-DOG approach). >give another. Let's agree to a definition: a "commuter car" is just >simple, basic transportation with good mileage, etc. - no extras. >Now, what _I_ want from a computing environment is a collection of >tools analogous to commuter cars (at least - I'll accept a tool that >does more, but not one that does less). What "UNIX think" wants to >give me is a set of components with which I must reconstruct a car >every time I drive. Again, a stupid analogy. If cars could be assembled from raw components with a few keystrokes in a matter of seconds, the "UNIX think" car would be wonderful. Tailor your car to whatever immediate need you have. >'find' filters only list files that have been accessed or modified (each >a separate filter) _since_ 'n' days ago. There is no way of telling it >to list the files that were last modified _before_ a given date. And, RTFM. OUR version of find, at least, has a unary not operator, '!'. Use ! -atime or ! -mtime. "UNIX think"er and proud! -- "Uh, Air Zalagaza 612, we have engine failure and our port wing is about to drop off. We anticipate a crash situation at this time." The lavatory is engaged. From within, you hear what could be a pygmy hog giving birth to an unusually large litter.
jlg@lanl.gov (Jim Giles) (01/14/91)
From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): > [...] > And you've been using UNIX for ten years? The shell does wildcard > substitution, not ls. You could just as easily type 'echo x*y'. Yes, you could type 'echo x*y' - which would write the string 'x*y' on your terminal. The shell does no wildcard substitution on any argument _automatically_. The tool has to ask for the functionality. Doesn't effect the validity of my previous point any. The use of 'ls x*y' is redundant with 'ls | grep x*y' in contradiction to the "one tool = one simple function" paradigm. In fact, the paradigm itself is a fraud. Nearly all UNIX tools have options and arguments which cause them to do several distinct things. The difference between that state of affairs and the one I would recommend is that the UNIX tools each implement a rag-tag assortment of capabilities. What I recommend is that each tool implement a complete set of closely related functions in a well thought out way. J. Giles
floyd@ims.alaska.edu (Floyd Davidson) (01/14/91)
In article <11305@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): >> [...] >> The advantage of UNIX is that tools are trivial to the point of >> doing just one basic thing. As a result each user can easily >> build larger tools to do *anything*. [...] > >By this logic, ls doesn't fit the paradigm. I can (on any UNIX) >do 'ls x*y' and get all the files whos names begin with x and end >with y. By the paradigm you just stated, I _should_ have to do >'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >that ls should have a built-in filter on file names. My claim is The fact is, _even_ after ten years of using UNIX, you are still refusing to *learn* UNIX. It is very hard to argue against something you don't understand. Several of you statements, including the one above, have been prime examples. Why not be honest about it. You don't want to learn UNIX. Fine, I have the same feeling about MS-DOS. I'm quite willing to admit that it is just the right thing for millions of computer users, but *I* don't want to learn it. That does not make MS-DOS a worthless thing. (It may in fact be worthless, but certainly not because it has no attractions for me!) You don't want to learn UNIX. Fine. Don't. But you are telling us an awful lot about yourself by arguing that you know it... Floyd -- Floyd L. Davidson floyd@ims.alaska.edu Salcha, AK 99714 paycheck connection to Alascom, Inc. When I speak for them, one of us will be *out* of business in a hurry.
quale@picard.cs.wisc.edu (Douglas E. Quale) (01/14/91)
In article <11305@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >that ls should have a built-in filter on file names. Jim, once before you challenged someone to say that you don't know anything about Unix. Ok, you don't know anything about Unix, and the above misstatement proves it. ls(1) doesn't have any built in filters on file names. The wildcards are part of the shell, not the command or OS kernel. -- Doug Quale quale@picard.cs.wisc.edu
barmar@think.com (Barry Margolin) (01/14/91)
In article <1991Jan13.113349.21937@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: >It hardly seems correct to associate bad programming with a >particular OS. At least not without backing it up with some >statement about what characteristics of the OS lead to bad >programming. It may or may not be true that UNIX encourages >bad programming, but you are saying something to the effect >that UNIX is bad because it has C compilers available for >it and C uses goto's, therefore UNIX is bad. May be, but >not for that reason, because it is basically true of all OS's. I didn't start reading this thread until its name changed to "UNIX mind-set", so maybe I missed the precise remark you are referring to. However, what I've seen since then were complaints about the design of user interfaces to utility commands, not about "bad programming" per se. In this case, it *is* reasonable to associate it with the OS, even though the problem doesn't actually stem from any technical aspect of the OS. Implementors of commands for an OS are generally encouraged to model them after existing commands, to maintain consistency. From the earliest days the journal papers about Unix have stressed a particular style of UI design. I'm sure that if I used the phrases "Unix-style pipe" or "Unix-style filter" when talking to a knowledgeable computer user they would understand the reference; there's more commonly associated with Unix than just inodes and fork(). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
root@lingua.cltr.uq.OZ.AU (Hulk Hogan) (01/14/91)
jlg@lanl.gov (Jim Giles) writes: >From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): >> And you've been using UNIX for ten years? The shell does wildcard >> substitution, not ls. You could just as easily type 'echo x*y'. >Yes, you could type 'echo x*y' - which would write the string 'x*y' >on your terminal. The shell does no wildcard substitution on any >argument _automatically_. The tool has to ask for the functionality. One last time. After you hit the RETURN key to terminate your input, the shell parses it. Leaving aside how it handles redirections and pipes, it globs the wildcards (which haven't been quoted) and then executes the specified programs with the globbed arguments. If there are no files matching the specification "x*y", then the result of the glob will be "x*y" in sh/ksh, and an error message in csh/tcsh. So "echo x*y" will print "x*y" in [k]sh, and an error message from [t]csh. Check the difference between entering echo * and echo "*". >Doesn't effect the validity of my previous point any. The use of >'ls x*y' is redundant with 'ls | grep x*y' in contradiction to the >"one tool = one simple function" paradigm. In fact, the paradigm >itself is a fraud. Nearly all UNIX tools have options and arguments >which cause them to do several distinct things. The difference between >that state of affairs and the one I would recommend is that the UNIX >tools each implement a rag-tag assortment of capabilities. What I >recommend is that each tool implement a complete set of closely >related functions in a well thought out way. On the whole, the extra functions are fairly logical, I think. Take the "-u" argument to "sort" which basically does the same as "uniq". Ok, it is unnecessary when you have "uniq", but I'd rather have both. Because I've read the manual, I know I can use "sort -u" and avoid an unnecessary pipe ("sort .... | uniq"). By all means, use the pipe if you want to. No one would deny the "creeping featurism" in Unix. Most people I know find it very very handy. /\ndy -- Andrew M. Jones, Systems Programmer, Internet: andy@lingua.cltr.uq.oz.au Centre for Lang. Teaching & Research, Phone (Australia): (07) 365 6915 University of Queensland, St. Lucia, Phone (World): +61 7 365 6915 Brisbane, Qld. AUSTRALIA 4072 Fax: +61 7 365 7077 "No matter what hits the fan, it's never distributed evenly....."
kers@hplb.hpl.hp.com (Chris Dollin) (01/14/91)
In this discussion, Jim Giles seems to be saying that useful functionality
(eg regular expression matching) should be available as a library for putting
into programs, and others seem to be saying it should be avilable for ad-hoc
(their terms) use from shells.
In fact they're both right - it should be available as *both*. Shell
programmming is programming, and grep is the shell procedure for regular
expression matching. C (or Ada, or Pop11) programming is programming, too, and
RE matchers should be available in *their* standard libraries. Why deny the
user of one language the capabilities of another, if they're conveniently
available? Then pick the language suitable for the job at hand.
It's a pain when different (shell-level) utilities have different
representations for the same thing (eg, RE matching), because one loses track
of which one does what. It's a pain when a utility doesn't export its useful
services (eg, matching code) into a library, because it can't then be
incorportated into ones own programs. It's a pain when the only way to use a
utility is for the user to run up a window and do mouse-clicks, because then
other programs ("real" code or scripts) can't use it conveniently; useful
abstractions (such as RE matching, or spell checking, or thesaurus lookup)
should be available as libraries, command-line programs, *and* snazzy
interfaces.
If only it were *easy*....
[This does'nt have much to do with the alleged "wrongness" of MS-DOS, and the
connection to architecture - apart from the software architecture point made in
the preprevious paragraph - is now tenuous enough that the thread ought to die
or move house.]
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."tom@bears.ucsb.edu (Tom Weinstein) (01/14/91)
In article <11313@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): >> And you've been using UNIX for ten years? The shell does wildcard >> substitution, not ls. You could just as easily type 'echo x*y'. > Yes, you could type 'echo x*y' - which would write the string 'x*y' > on your terminal. The shell does no wildcard substitution on any > argument _automatically_. The tool has to ask for the functionality. Argh! Was I unclear? You are completely, 100%, totally wrong. ls does absolutely no wildcarding. ls does not ask the shell to do so. There is a shell variable called noglob that tells the _shell_ whether or not to do it. No process external to the shell can set this variable. > Doesn't effect the validity of my previous point any. The use of > 'ls x*y' is redundant with 'ls | grep x*y' in contradiction to the > "one tool = one simple function" paradigm. Wrong. 'ls x*y', in the absence of shell wildcarding, would look for a file named x*y and list it, or its contents if it is a directory. 'ls | grep x*y' would do something completely different from 'ls x*y' in the presence of shell wildcarding. In particular, it would list each file on a seperate line. > In fact, the paradigm itself is a fraud. Nearly all UNIX tools have > options and arguments which cause them to do several distinct things. This may be true in some cases. I'm not at all sure that it is true in most. And even if it is, all you seem to be saying is that you would have split the functions up into tools in a different manner than the implementors of UNIX did. Your way may be better, or it may not be, but I hardly think it constitutes a good argument against UNIX. > The difference between that state of affairs and the one I would > recommend is that the UNIX tools each implement a rag-tag assortment > of capabilities. What I recommend is that each tool implement a > complete set of closely related functions in a well thought out way. Hmm, weren't you arguing against a tools approach a little while ago? Or do you mean applications instead of tools? I make the distinction because I'd view things like grep or awk as tools, and things like emacs or Microsoft Word as applications. If you really do mean tools, I'm a bit surprised as I thought you were just arguing against such an approach. -- He is Bob...eager for fun. | Tom Weinstein tom@bears.ucsb.edu He wears a smile... Everybody run! | tweinst@polyslo.calpoly.edu
mike (Michael Stefanik) (01/14/91)
In article <11305@lanl.gov> lanl.gov!jlg (Jim Giles) writes:
:[...] I can (on any UNIX)
:do 'ls x*y' and get all the files whos names begin with x and end
:with y. By the paradigm you just stated, I _should_ have to do
:'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized
:that ls should have a built-in filter on file names. [...]
Now wait a second here. For someone who has been using UNIX for over
ten years, you're a tad green. First of all, it is the shell, not ls,
that expands wildcards. Second of all, that grep expression you gave
is nonsense ... you're telling grep to look for any number of x's which
is then followed by a y. How about grep "^x.*y$" to do what you're
talking about. If you're gonna slam UNIX and come from the position that
you've used it for ten years and know it all, you better start showing
that you know what the hell you were doing for those ten odd years ...
And why the harping on pipes? Provide us with a better way for two processes
to communicate transparently and anonymously (ie: no special provisions made
within the programs themselves for said communication).
--
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."mike@bria.UUCP (Michael Stefanik) (01/14/91)
In article <11313@lanl.gov> lanl.gov!jlg (Jim Giles) writes: >From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): >> [...] >> And you've been using UNIX for ten years? The shell does wildcard >> substitution, not ls. You could just as easily type 'echo x*y'. > >Yes, you could type 'echo x*y' - which would write the string 'x*y' >on your terminal. The shell does no wildcard substitution on any >argument _automatically_. The tool has to ask for the functionality. << FLAME ON! >> The "tool has to ask for the functionality" of globbing? How does it do this, precisely? Send email to shell, asking it nicely? C'mon! Globbing is a builtin function of the shell; wildcards are resolved BEFORE the shell even forks and executes the command. So, tell us all, who are appraently so ignorant (nay, but mere intellectual pygmies on the broad shoulders of your intellect), how does the program ask for globbing after it has already been done, and the arguments are sitting in it's stack? Please, enlighten us all. << FLAME OFF >> And don't you just hate the word "paradigm" after it's been used twenty or thirty times? How about "example" for a change. I have a Webster's dictionary too, ya know. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
cyliax@ecn.purdue.edu (Ingo Cyliax) (01/14/91)
In article <11267@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: |> |> Quite so. In my case, well over 90% of such searches are followed by |> an edit of the file in the neighborhood of the found word. So - over |> 90% of such searches I do are from within an editor - which should have |> such searches built-in. Much of the rest of the time, what I want |> the search to do is show me something of the context of each place |> where the pattern matches - usually, one line isn't enough of that |> context (so, in this case, I often end up using the editor again). Grep will also tell you what line it found the pattern on, it's trivial to combine grep with sed/wak in a shell script or alias and have it start up an editor on the file and line that it found the pattern on. |> |> So, the remaining few times I need a grep-like functionality are to |> make up for the lack of such a feature in tools like ls. Here is |> where I make my once or twice a month use of grep. I should be able |> to say something like 'ls -owner jblow' and get a list of all files |> in the directory belonging to joe blow. I _could_ write a shell |> script to do this (use awk to extract the owner field from an 'ls -l' |> sequence, then grep for 'jblow'). What I usually end up doing, though, |> is writing 'ls -l | grep jblow' - which has the unfortunate habit |> of also listing files whos names contain 'jblow'. Using grep this way |> doesn't exemplify the strength of grep - it simply (almost) covers |> a weakness in ls. You could use find for this. find . -user jblow -print will do this. |> |> A production quality ls would have the capability to filter any |> of the fields of a file description in generally useful ways. |> For example, what about 'ls -before 1/1/90' to list all files |> created before Jan. first 1990? Try to do _that_ with grep. I would use find for this as well. |> |> Then you agree that a version of ls which does the above should _not_ |> be written as a shell script? Indeed, the functionality of filtering |> on the creation dates would probably be easier from within a program |> than for a script. In any case, utilities should be written to the |> same standards of quality and efficiency as and other production code |> and, by your own statement, should not be written as scripts. Well, ls is a program that give you informattion about a file or directory. Find will search the filesystem for files that match certain criteria. Grep searches for regular expressions in the file contents. These are all tools that do a specific task. Combine them and you can do almost anything you want to. That is the power of Unix. |> |> Note: the use of ls as an example in this note is just that: an example. |> The same kind of argument could be applied to many other tools (like |> other system inquiry stuff: ps, who, etc.) - which should all contain |> built-in capabilities to filter the information they produce. I don't |> want to get into a long discussion about specific properties of ls like |> this one going on about grep. The grep utility itself I chose as a |> specific example of a whole class of UNIX utilities whose functionality |> should be contained in appropriate other programs (like dd, tr, etc.). That's just the point of Unix. Once you have mastered the use of grep, awk and the other text manipulation tools (there aren't that many, BTW), you can use them with commands like who or whatever to do the specific filtering you want. Well, you should pick up some good books on Unix Shell programming and Using Unix. I bet you have a whole shelf full of DOS books as well as books on all the tools you use under DOS (Word, Lotus 1-2-3 etc.), so why not invest in some books about Unix...? |> J. Giles -ingo
pfalstad@phoenix.Princeton.EDU (Paul John Falstad) (01/14/91)
In article <8166@hub.ucsb.edu> tom@bears.ucsb.edu writes: >In article <11313@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: >> Yes, you could type 'echo x*y' - which would write the string 'x*y' >> on your terminal. The shell does no wildcard substitution on any >> argument _automatically_. The tool has to ask for the functionality. >Argh! Was I unclear? You are completely, 100%, totally wrong. ls does >absolutely no wildcarding. ls does not ask the shell to do so. There Perhaps he uses sh, and tried "echo x*y" from the command line just before he posted. It worked, probably because he doesn't have any x..y files in his directory. >> Doesn't effect the validity of my previous point any. The use of >> 'ls x*y' is redundant with 'ls | grep x*y' in contradiction to the >> "one tool = one simple function" paradigm. Even if you turned on globbing for the "ls x*y" and turned it off for "ls | grep x*y", this would still be wrong, since the regular expression "x*y" does not do the same as the shell pattern "x*y". The latter matches filenames starting in x and ending in y, while the former matches filenames containing a string consisting of an arbitrary number of x's followed by a y. Ignoring this, however, you might perhaps have a point (on ls x*y being redundant) if the shell did globbing only for ls. It does globbing for all commands, however. What about rm x*y? I suppose you could get the same effect by using rm `ls | grep '^x.*y$'`, but it takes longer to type and is less efficient. I'm not sure if the shell is really a 'tool', however. I don't think ksh, bash, and tcsh follow the "one tool = one simple function" paradigm. The shell is more of an application IMHO. -- "Uh, Air Zalagaza 612, we have engine failure and our port wing is about to drop off. We anticipate a crash situation at this time." The lavatory is engaged. From within, you hear what could be a pygmy hog giving birth to an unusually large litter.
ken@csis.dit.csiro.au (Ken Yap) (01/15/91)
>I'm not sure if the shell is really a 'tool', however. I don't think >ksh, bash, and tcsh follow the "one tool = one simple function" >paradigm. The shell is more of an application IMHO. Perhaps, but people often forget that the shell is a nice place to pipe a stream of commands. I experienced an epiphany when I saw a guru do ls *.pas | sed 's/\(.*\).pas/mv & \1.p/' | sh And another, reparing a root filesystem with cat corrupted, did sh -nv file to view the file. Followups redirected out of comp.arch.
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/15/91)
jlg@lanl.gov (Jim Giles) writes: >A production quality ls would have the capability to filter any >of the fields of a file description in generally useful ways. >For example, what about 'ls -before 1/1/90' to list all files >created before Jan. first 1990? Try to do _that_ with grep. I believe that the OS ne Holy Grail that you are looking for is called VMS and is a product of Digital Equipment Corporation. You may want to look in to its features -- it will probably satisfy a lot of your gripes with Unix. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/15/91)
In comp.arch you write: >> [...] There >> are better ways. Try 'find'. (You may want to grep the output.) >Well, 'find' _does_ have filters built-in for similar time related >filtering (against the advice you have been offering for UNIX tools). I don't think the arguers have been arguing against *any* kind of extra capability in a particular tool or even a whole class of tools. Rather, an elegant simplicity represented in a modestly greater than minimum functionality. If you imagine tools to be little marbles or nodules, each of which may be connected to each other only at certain points (kind of like molecules, i'm sure), then we are not arguing for a marble that has zero, one, or two connection points only. Zero is a degenerate case and seems rather useless. O O O O O One connection point only is almost as useless: O--O O--O O--O Two connection points is what i imagine how you see unix tools in general and, if that were the case i would tend to agree with you. O--O--O--O--O But, most unix tools can be used in several different ways so that the same end result can be achieved in several different ways, according to the needs of a particular situation or the druthers of the programmer/user: O--O O | | O--O--O--O | O--O--O This has a much more multi-dimensional feel to it, hmmm? Building blocks in which you had to attach everything the same way would truly be dull and not terribly benificial. However, look at all the wonderful varieties of brick buildings there are in the world. Hardly any of them are the same, and yet, they are all built with same type of brick. >I'm happy to see that you regard this as a better way. However, the >'find' filters only list files that have been accessed or modified (each >a separate filter) _since_ 'n' days ago. There is no way of telling it ^^^^^^ >to list the files that were last modified _before_ a given date. It is usually potentially dangerous to make statements coached in absolutes. "No way" is a pretty firm statement in my opinion and, in this case, may be relatively easily refuted. I refer you to the man page for find(1) [which would have benefited you to have read before posting]: In the descriptions, the argument "n" is used as a decimal integer where "+n" means more than "n", "-n" means less than "n", and "n" means exactly "n". Thus, a sample command to do what I think you claim can't be done with find is: find . -mtime -14 -print #find files modified more than 14 days ago Or perhaps you meant before a specific date: touch 1013073077 /tmp/$$ find . ! -newer /tmp/$$ -print #find files modified before oct 13, 1977 -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/15/91)
jlg@lanl.gov (Jim Giles) writes: >From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): >> [...] >> And you've been using UNIX for ten years? The shell does wildcard >> substitution, not ls. You could just as easily type 'echo x*y'. >Yes, you could type 'echo x*y' - which would write the string 'x*y' >on your terminal. The shell does no wildcard substitution on any >argument _automatically_. The tool has to ask for the functionality. I suspect that you may have, when you saw Tom Weinstein claiming you could type "echo x*y", immediately tried the command and discovered it typed the literal string "x*y" instead of expanding the wildcard characters. I have discovered that the majority of beginning computer users regard computer operating systems and their respective command interpreters as some macabre joke perpetuated upon them by some evil computer scientist who forces apparently random commands and command sequences upon innocent users. Without a general understanding of the basic underlying structure, computers (as well as human languages if you think about it) do often appear capricous and arbitrary. Your statement above about the "echo x*y" command is starting to convince me that you fall into that group of beginning computer users. In deference to you, I believe that you must have made a mistake and didn't mean to say what you said; however, if you uphold the veracity of your claims, I would suggest that you reevaluate your analysis of the various unix tools because if you are mistaken about one of them, you may possibly be mistaken in the others as well. If the tool in question *did* ask for the functionality of wildcard expansion and there didn't happen to be any files in the directory that began with "x" and ended in "y", what would be the result? Would the argument disappear? Or perhaps be replaced by the token "No_Matching_Files"? These are all possibilities and a matter of definition, i suppose. In the unix case, it has been defined (good or bad) that the argument be passed through to the application unchanged. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/15/91)
pfalstad@phoenix.Princeton.EDU (Paul John Falstad) writes: >Even if you turned on globbing for the "ls x*y" and turned it off for >"ls | grep x*y", this would still be wrong, since the regular expression >"x*y" does not do the same as the shell pattern "x*y". The latter >matches filenames starting in x and ending in y, while the former matches >filenames containing a string consisting of an arbitrary number of x's >followed by a y. Except that because x*y was not quoted, the shell would expand the pattern before grep saw it. Grep's actions would depend on what x*y expanded to. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
fanning@desktech.DTI.CPS.COM (Blaise Fanning) (01/16/91)
> >A production quality ls would have the capability to filter any >of the fields of a file description in generally useful ways. >For example, what about 'ls -before 1/1/90' to list all files >created before Jan. first 1990? Try to do _that_ with grep. > **Disclaimer : I like both Unix and VMS. ** What I think I'm hearing is that you feel that each command line you type should consist of a single command with all of the options that you need to accomplish a single (sometimes trivial,sometimes complex) task. In that case, VMS is the operating system for you! I have been both a VMS and a Unix user in the past and have found that either OS is sufficient to get my job done. Each, of course, takes some getting used to, and switching from one to the other can be frustrating. This is because the two operating systems come from entirely different directions in terms of how they are used. VMS is meant to be used by people who, like Mr. Giles, like to add options to a single command to accomplish what they need. VMS is so option-laden that you can sometimes guess options to commands without knowing that they exist: dir /before=1-jan-1990 The "before" keyword is used in a few different places, but DIR and BACKUP leap to mind. In VMS, sometimes you can guess options that are undocumented. (Have they included SET TIME/CLUSTER in the online documentation yet???) Unix, on the other hand, trims down individual commands by forcing users to understand exactly what they want to do and allowing them to do it. (Note that the word "forcing" in the last sentence could truthfully be replaced by "empowering".) My point is this: VMS offers Mr. Giles what he wants and Unix does not. Why, then, is he championing DOS, which does not empower users to do much of anything on a single command line? Is he claiming that he has fewer than 9 things that he *ever* wants to do? DOS : $100 Simple Command Utilities : 9 @ $100 (pretty cheap) = $900. Let's be a little consistent here. If the thread converns whether Unix or DOS is better. Let's get away from saying things like "It's hard to do this thing-that-I-can't-do-anyway-in-DOS in Unix, so DOS is better...". Blaise __________________________________________________________________________ Blaise Fanning Principal Engineer DeskStation Technology Lenexa, KS
root@lingua.cltr.uq.OZ.AU (Hulk Hogan) (01/16/91)
wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) writes: >root@lingua.cltr.uq.OZ.AU (Hulk Hogan) writes: >>jlg@lanl.gov (Jim Giles) writes: >>>From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein): >>>> And you've been using UNIX for ten years? The shell does wildcard >>>> substitution, not ls. You could just as easily type 'echo x*y'. >>>Yes, you could type 'echo x*y' - which would write the string 'x*y' >>>on your terminal. The shell does no wildcard substitution on any >>>argument _automatically_. The tool has to ask for the functionality. >>One last time. After you hit the RETURN key to terminate your input, >>the shell parses it. Leaving aside how it handles redirections and pipes, >>it globs the wildcards (which haven't been quoted) and then executes the >>specified programs with the globbed arguments. >Wrong. It first checks the variable "noglob" and does only substitutions >if this is unset. So, in a way, the statement is correct, that the >shell performs no automatical wildcard substitutions... :-) Wrong. (My turn for nitpicking!) In csh/tcsh, there is a noglob variable. In sh, you have to "set -f". Perhaps I should have mentioned that in my article, but I thought it would only complicate things, as simple points were having tremendous trouble being understood. Jim Giles said that the tool had to ask the shell to glob wildcards. This was patently false. >Beside this needle-picking, i would agree to Jim Giles original arguments >in the following sense: The UNIX shell command language (in which you >might view commands like "grep" and "ls" as standard procedures) is to >weak to handle real information processing problems. OK, you can do >nearly anything, but how? Its a mess to work with this ugly >non-straightforward kinds of quotations etc. pp. seriously. But what is the solution? I love C, and I agree (see later articles by me and others) that many of the great things you can do on the Unix command line can't be done in easily in C because the libraries don't support them (and popen(3)'ing subshells for globbing etc is a real pisser). >On the other hand, DOS has no command "language" at all ... but a lot >of comfortable "harded-wired" information managers, f.i. norton >commander. You cannot freely configure this tools for your needs. >So you go and buy the next one ... Thank God Unix doesn't do the DOS "solution" of giving you a braindead .BAT language and bundling BASIC. (Maybe this was Microsoft's version of giving the user shell and a bundled C compiler... :) Whilst shell script is missing lots of programming stuff you get in C (although the newly introduced functions are a huge gain), it is much easier for most people to use and very fast at hacking up new commands. For the non-computer-professional, being given shell is a pretty good compromise IMHO. For the professional, it saves endless vi/cc-ing every time you want to create a new tool. /\ndy -- Andrew M. Jones, Systems Programmer, Internet: andy@lingua.cltr.uq.oz.au Centre for Lang. Teaching & Research, Phone (Australia): (07) 365 6915 University of Queensland, St. Lucia, Phone (World): +61 7 365 6915 Brisbane, Qld. AUSTRALIA 4072 Fax: +61 7 365 7077 "No matter what hits the fan, it's never distributed evenly....."
xxremak@csduts1.lerc.nasa.gov (David A. Remaklus) (01/19/91)
>In article <11305@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): >>> [...] >>> The advantage of UNIX is that tools are trivial to the point of >>> doing just one basic thing. As a result each user can easily >>> build larger tools to do *anything*. [...] >> >>By this logic, ls doesn't fit the paradigm. I can (on any UNIX) >>do 'ls x*y' and get all the files whos names begin with x and end >>with y. By the paradigm you just stated, I _should_ have to do >>'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >>that ls should have a built-in filter on file names. My claim is > > (stuff deleted) The truth is, the 'ls' command does *NOT* have the 'filter' as is claimed. It is the shell that expands x*y into the names of all the files that begin with x and end in y. The purpose of the ls command is to format this list and optionally provide information about the files from the inode of the files. The 'fact is', the ls command is a tool that does one basic funtion, provide a formatted listing of information about a specified list of files. -- David A. Remaklus Currently at: NASA Lewis Research Center Amdahl Corporation MS 142-4 (216) 642-1044 Cleveland, Ohio 44135 (216) 433-5119 xxremak@csduts1.lerc.nasa.gov
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/19/91)
In article <1991Jan18.163230.11695@eagle.lerc.nasa.gov> xxremak@csduts1.UUCP (David A. Remaklus) writes: | The 'fact is', the ls command is a | tool that does one basic funtion, provide a formatted listing of information | about a specified list of files. And ls is a tool with built-in sort so you don't have to pipe the output of list through sort anymore ;-) -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) A system without MS-DOS compatibility is like a rock without mayonnaise
peterb@ptlcamb.UUCP (01/19/91)
>/* Written 5:05 pm Jan 13, 1991 by jlg@lanl.gov in ptlcamb:comp.arch */ >From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): >> [...] >> The advantage of UNIX is that tools are trivial to the point of >> doing just one basic thing. As a result each user can easily >> build larger tools to do *anything*. [...] > >By this logic, ls doesn't fit the paradigm. I can (on any UNIX) >do 'ls x*y' and get all the files whos names begin with x and end >with y. By the paradigm you just stated, I _should_ have to do >'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >that ls should have a built-in filter on file names. My claim is >that any tool which reports information summaries (like ls, ps, who, >etc.) should have the built-in capability to filter on any of the >categories of information that it reports. No, the filter is not in ls, its in the shell. Try echo x*y some time. This is the beauty of UNIX shells. Every tool has the same filename matching and expansion, and consistent wildcarding. >Your above statement is perhaps the single thing I object to most in >"UNIX think". This seems to be a discussion of analogy, so I'll >give another. Let's agree to a definition: a "commuter car" is just >simple, basic transportation with good mileage, etc. - no extras. >Now, what _I_ want from a computing environment is a collection of >tools analogous to commuter cars (at least - I'll accept a tool that >does more, but not one that does less). What "UNIX think" wants to >give me is a set of components with which I must reconstruct a car >every time I drive. UNIX gives you the capability to build the car and drive it. If you want to reuse that car, then save the commands in a script somewhere. Everybody would think you were an idiot if you rebuilt your engine EVERY morning before you drove to work. >> [...] You want *everything* built >> in (at least everything that you would use) to every program. > >No, that's not exactly what I want. To keep to the car analogy, I >don't ask for all cars to be limos with the TV, phone and bar, etc.. >What I _do_ ask is that each be equipped for all aspects of its >basic functionality. I don't want to get into the car and end up >with "Oh damn. I forgot to install the engine this morning." Ok, >so you say "build a script to put the engine in". Fine, except >scripts are inefficient and the engine _really_ should have been >there to begin with. So should things intimately connected with the >transport function - even if not really _required_ for it (like >headlights, windshield wipers, and rearview mirrors). I don't care for a limo either, but when the problem requires it, I know that I can build one both quickly and cheaply. With UNIX, I have my choice of different Engines, everything from a PeeWee to a Formula One V12. Also, why should I have windshield wipers if all I need it for is to lug dirt around the yard? >> [...] >> PS Why use grep for the 'ls -before 1/1/91' command. [...] > >Well actually, I was arguing _against_ the use of grep for this. >grep happened to be the specific example of a general class of >tools that I was speaking against. There is no other filtering >tool that takes a list of lines, each containing a date field, >and passes only those whose date field preceeds a specific date. I don't see this tool distrubuted in any other OS either. But I can write one in about 40 lines of script and subfilters. I'm sure you could too. Don't complain that your 'commuter' car only comes in black, Ok? >> [...] There >> are better ways. Try 'find'. (You may want to grep the output.) > >Well, 'find' _does_ have filters built-in for similar time related >filtering (against the advice you have been offering for UNIX tools). >I'm happy to see that you regard this as a better way. However, the >'find' filters only list files that have been accessed or modified (each >a separate filter) _since_ 'n' days ago. There is no way of telling it >to list the files that were last modified _before_ a given date. >And, indeed, that's the other problem with 'find': I usually don't know how >many days it's been since a given date (my example was 1/1/90 and not >this year), at least, not off the top of my head. In SysV, there is a simple way: touch -m "date" /tmp/foo find . \! -newer /tmp/foo -print rm /tmp/foo The ! construct reverses the sense of the test. -newer compares the data of the file and reports if the selected file is newer (by one second or more) than the reference file. Also, the seperate filters are built into find, not seperate subprocesses. Read the man pages some more, then flame about whats not there. >J. Giles -- Peter Barada / ...!{harvard|bu.edu|think|uunet}!ima!ptlcamb!peterb Phoenix Technologies Ltd. / Peripherals Group / 617-551-5000 (USA) Clone the Bone!!! / Opinions are mine; Phoenix cloned them from me...
sjg@melb.bull.oz.au (Simon J Gerraty) (01/19/91)
In <11305@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): >> [...] >> The advantage of UNIX is that tools are trivial to the point of >> doing just one basic thing. As a result each user can easily >> build larger tools to do *anything*. [...] >By this logic, ls doesn't fit the paradigm. I can (on any UNIX) >do 'ls x*y' and get all the files whos names begin with x and end >with y. By the paradigm you just stated, I _should_ have to do >'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized >that ls should have a built-in filter on file names. My claim is Could we please all drop this useless discussion? People are slagging off at OS's with out any understanding of what they are talking about. For the record, under UNIX the _shell_ expands x*y not ls. Under MS-DOS, each command has to do its own wild-card matching because COMMAND.COM does not. I beleive Mr. Giles has simply helped Mr. Davidson make his point. Besides religous issues like "my favourite {editor,OS,drink,...} is {emacs,unix,coke,...} because ..." are never solved by arguments, rational or otherwise. -- Simon J. Gerraty <sjg@melb.bull.oz.au> #include <disclaimer,_witty_comment>
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (01/22/91)
The problem with Mr. Giles and other people with similar viewpoints is that they don't hear you when you say "flexiblity". To them it is just another marketing buzz word thrown in off the top of ones head, but nothing that really conveys any meaning. You see Mr. Giles knows THE SINGLE BEST WAY TO DO *ANYTHING* ON A COMPUTER. From his point of view all these rinky-dink little utilities that need to be hooked together are just a waste of time because why should you keep hooking them together when he knows, *beforehand* mind you, the way they _should_ have been hooked together in the first place ??!! Never mind that *you* might like doing things in a slightly different fashion, never mind that *you* might see the problem from a slightly different angle, J. Giles KNOWS ! If you had just let him design your system you would have THE SINGLE BEST WAY TO SOLVE YOUR PROBLEM right at your fingertips in one neat little package and never mind all this "pipes and filters" garbage. It's only mortals like us, who don't possess the ability to conceive of every possibile use for the systems we design, that have to worry about "flexibility" or "expandability". take ever combination, take every consideration take a few weeks off - talking heads Gilbert Pilz Jr. "Stay outta churches son, all they got the key to is gil@banyan.com the shithouse." - last words of Mortimer Carsons
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (01/22/91)
In article <355@bria> mike@bria.UUCP (Michael Stefanik) writes: }In article <11313@lanl.gov> lanl.gov!jlg (Jim Giles) writes: }The "tool has to ask for the functionality" of globbing? How does it do }this, precisely? Send email to shell, asking it nicely? C'mon! Globbing }is a builtin function of the shell; wildcards are resolved BEFORE the }shell even forks and executes the command. So, tell us all, who are appraently }so ignorant (nay, but mere intellectual pygmies on the broad shoulders of }your intellect), how does the program ask for globbing after it has already }been done, and the arguments are sitting in it's stack? Well the shell could pass a copy of the unglobbed as well as globbed arg's to the program. I'm not going to comment on the reasonableness of this whole thread, but where theres a will theres a way :-) -- Stuart Lynne S&L Investments Ltd. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca