Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!preece%mycroft@gswd-vms.Gould.COM From: preece%mycroft@gswd-vms.Gould.COM (Scott E. Preece) Newsgroups: comp.unix.wizards Subject: Re: Large programs Message-ID: <9676@brl-adm.ARPA> Date: Wed, 7-Oct-87 13:51:20 EDT Article-I.D.: brl-adm.9676 Posted: Wed Oct 7 13:51:20 1987 Date-Received: Sat, 10-Oct-87 09:56:56 EDT Sender: news@brl-adm.ARPA Lines: 66 From: Eddie Wyatt > > 1) entering a command which uses three to seven different small > > programs, all piped together, is a *PAIN* in the arse! In many cases, a > > single command is much more desireable, certainly less prone to errors, > > and always eaiser and faster to use. > > Is it?? What options to "ls" sorts by time last modified, time created, > prints in single columns, multi columns..... ---------- Well, actually, I don't have any trouble keeping those in my head, BECAUSE I use them all the time. I also alias some things I use occasionally to a single command. Aliases obviously vitiate this argument in any case: you can tie that complex pipe to a simple command so you don't have to type so much. > 1) Once you know how to perform some operation on some data > (like sorting the output of ls by file size) you can extend it > to any command (like sorting the output of df by size). ---------- I often think the ls example is misleading. There are some Unix tools which work very well in a pipes and filters arrangement and many others that don't. Ls happens to work pretty well for the obvious cases and less well for some others (sure, it's possible to do a sort by access date ls using pipes, but it's a real pain. So, you end up tying it to a shell script that cans the sort specification for you. Now you have to remember the name of the shell script. So much for ease of use.) > 2) From the implemation standpoint, modularity can reduce the > amount of duplicated efforted. -- Does ls bother calling > sort for its sorting of output or did someone implement yet > another sort in the ls code?? ---------- There is no guarantee that the system sort is the right sort for any particular sorting application. It's very likely that the sorting required by ls can be done faster and cheaper using an internal sort. If it's done enough, that's a good trade off. > 3) Uniformity is achieved. Does the -v switch for ls do the same > thing for cat?? Probably not. (Though I have to admit some > attempt at uniformity in switches is made: -i for cp, rm, mv > does basically the same thing) ---------- I don't see what this argument means. Why does contruction from pipes say anything about uniformity of switches? > Admittedly, speed in execution is one of the prices you pay for > taking the modular approach, but things aren't all that bad. Piped > processes get executed concurrently. If you had a parallel processor, > who knows, maybe each program could be executed on a different > processor. The pipes could provide a course grain break down of the > computing needed. 8-} ---------- And a fine-grained parallelism approach would get you the same gain from the monolithic program, without the pain of having to exec several different programs to do one (external) function. Performance matters; it makes blindingly obvious sense to work to improve performance of the things that get done most. I think you'll find that ls is one of the two or three most used (by humans) commands on most Unix systems. It makes sense to make it do its most common functions efficiently. It also makes sense to make it compatible with other tools, so that more obscure things can be done in combination. The tool composition approach is wonderful and is obviously an important thing for us to provide in our systems, but to jump from that to a belief that no tools should support compound functions is just silly.