gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/26/88)
In article <748@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >Does anyone know why the SVID only lists the "-s" option? Maybe the people who drew up the SVID wanted to leave out as much cruft as possible?
dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/26/88)
In article <8985@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>Does anyone know why the SVID only lists the "-s" option? > >Maybe the people who drew up the SVID wanted to leave out as much cruft >as possible? Well, now, it might be cruft, but -u is *useful* cruft. I have a shell script containing the line: /bin/cat -uv "$file" | /usr/ucb/more -10d I couldn't get it to work right without the -u option. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/27/88)
In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Well, now, it might be cruft, but -u is *useful* cruft. ... >I couldn't get it to work right without the -u option. The -u option is "useful" only when the implementation of "cat" is broken to start with. A good implementation benefits not at all from the -u option.
scs@athena.mit.edu (Steve Summit) (11/28/88)
In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I have a shell script containing the line: > > /bin/cat -uv "$file" | /usr/ucb/more -10d Which is exactly why an option like -v (make control characters visible) should be in a file-viewing utility like more, and not in a concatenation utility like cat. Steve Summit scs@adam.pika.mit.edu
mike@stolaf.UUCP (Mike Haertel) (11/29/88)
In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Well, now, it might be cruft, but -u is *useful* cruft. I have a shell >script containing the line: > > /bin/cat -uv "$file" | /usr/ucb/more -10d > >I couldn't get it to work right without the -u option. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi As far as I know, -u basically means while ((count = read(fd, buf, sizeof buf)) > 0) write(1, buf, count); as opposed to using fread and buffered stdio. This makes a difference when copying between devices that don't necessarily return as many bytes as you asked for in read (e.g., ttys). For example, consider the following cheapo write(1): $ cat > /dev/somebody_elses_tty With raw I/O it works as expected, with fread it doesn't. If your loop is while ((c = getchar()) != EOF) putchar(c); then it works as expected, at least on the machines I have used. I believe (somebody at Bell Labs correct me, maybe?) that -u was added in going from version 6 to version 7 when cat was rewritten from using assembly language and something equivalent to getchar() to C and fread. And of course, the existence of one flag (-u) was too much for the alphabet soup people to resist, so we get REAL cruft like -v, -s (which means different things on BSD and Sys V!) and all that . . . The cat I use (one I wrote myself) doesn't take any switches. It's also faster. -- Mike Haertel mike@wheaties.ai.mit.edu In Hell they run VMS.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/29/88)
In article <783@stolaf.UUCP> mike@wheaties.ai.mit.edu writes: >With raw I/O it works as expected, with fread it doesn't. Yup, that's the whole point. (not really "raw I/O") >If your loop is > while ((c = getchar()) != EOF) > putchar(c); >then it works as expected, at least on the machines I have used. No, that implementation is broken too. >The cat I use (one I wrote myself) doesn't take any switches. >It's also faster. Same for the one I recently posted.
henry@utzoo.uucp (Henry Spencer) (11/30/88)
In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > /bin/cat -uv "$file" | /usr/ucb/more -10d > >I couldn't get it to work right without the -u option. This is a bug (albeit a long-standing and widespread one) in your cat. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jc@minya.UUCP (John Chambers) (12/06/88)
In article <8160@bloom-beacon.MIT.EDU>, scs@athena.mit.edu (Steve Summit) writes: > In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >I have a shell script containing the line: > > > > /bin/cat -uv "$file" | /usr/ucb/more -10d > > Which is exactly why an option like -v (make control characters > visible) should be in a file-viewing utility like more, and not > in a concatenation utility like cat. Nah; you're both wrong. It belongs in a separate program that does only that one job, and the above pipeline should have three processes, not two. It doesn't belong in more, because it's useful in situations other than just displaying on a terminal. I've written silly little filters like this on many occasions, and I've invariably been glad that I wrote them as separate programs, so I could interpose them between random pairs of other programs. It also doesn't belong in more, because more's job is to paginate, and it shouldn't have to do extraneous junk like text translation. Suppose I want some other translation other than the one programmed into more? I'm outa luck, right? If it's a separate process, then I can develop a repertoire of them for different terminals or different languages or ..., and the user can call the right one. You could make a feeble argument that it's at least OK to put it into cat. This makes "| cat -v |" the character-translate process in the pipeline. But cat's real job is to catenate files. It shouldn't do anything other than that. What ever happened to the original Unix Philosophy of lots of little programs, each of which did exactly one job well, and which could be fitted together to do bigger jobs? I've noticed that lots of people seem to dislike this approach, but I've yet to see any cogent argument against it. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
charlie@queets.stat.washington.edu (Charlie Geyer) (12/11/88)
In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >What ever happened to the original Unix Philosophy of lots of little >programs, each of which did exactly one job well, and which could be >fitted together to do bigger jobs? I've noticed that lots of people >seem to dislike this approach, but I've yet to see any cogent argument >against it. > Simple psychology. Who wants to write a program that just concatenates files? If your task is to write a text editor but your real ambition in life is to write a Lisp interpreter, what do you do?
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >What ever happened to the original Unix Philosophy of lots of little >programs, each of which did exactly one job well, and which could be >fitted together to do bigger jobs? I've noticed that lots of people >seem to dislike this approach, but I've yet to see any cogent argument >against it. In the standard shell environment, it's obviously the best approach. The only technical argument I know of is that if too many processes have to be invoked simultaneously to get a task done, some system or user limit may be exceeded. I have almost never run into this in practice, however. In a Macintosh-like environment, the situation is radically different, because there is no good way to combine independent processes into a larger unit. This frustrates the heck out of me when I'm using those systems! In such an awful environment, so-called "integrated applications" with maximal number of imbedded features are practically required to get the job done. Of course, one useful integrated application would be a UNIXy shell with pipes and a bunch of basic UNIXy utilities. So much for the icon interface.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <1111@entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: >Simple psychology. Who wants to write a program that just concatenates >files? If your task is to write a text editor but your real ambition in >life is to write a Lisp interpreter, what do you do? On UNIX we already have a program that concatenates files. It is one of the first programs I write for a new non-UNIX system. A professional tasked with developing a text editor will develop a text editor. If he's really good and there are no particular design constraints (unlikely), the resulting editor will be extremely flexible, powerful, and easy to use. It may even support a form of LISP, but only because it's a good way to achieve the previously mentioned goals, not because it's what the programmer would rather do. I manage to find occasion to develop interesting (to me) algorithms, designs, and methods in the course of working on various projects. So long as one is aware of a variety of possible techniques, sooner or later the opportunity to apply some of them will arise. If your task includes software system design, then knowledge of the toolkit approach gives you a powerful advantage over those who don't know how to plan for the unplanned.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/12/88)
In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >What ever happened to the original Unix Philosophy of lots of little >programs, each of which did exactly one job well, and which could be >fitted together to do bigger jobs? With the right point of view, this question becomes non-sequitorial. From the user's point of view, where the code lies (i.e., whether it's in separate programs called ex and vi, or in one program with two links) is not relevant. What matters is the way the user interface looks. Think of "cat", "cat -u", and "cat -s" as separate programs. Then create a pipeline like this: cat files ... | cat -u | cat -s Now go "AHA!" with the realization that both cat -u and cat -s will accept multiple filenames, so cat alone isn't needed any more: cat -u files ... | cat -s At this point the purist stops and is deliriously happy at using two small, single-purpose utilities. The pragmatist continues to optimize by eliminating an extra process and an extra pipe and gets: cat -us files ... Whether you need three single-purpose utilities, or a single triple-purpose utility, the 4.3BSD cat delivers. By the way, if you took the one-function-per-program philosophy too far, you would have separate commands such as cc-g, cc-O, cc-ld, cc-E, etc., instead of having a single front-end called cc that accepts a large number of switches. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
mike@thor.stolaf.edu (Mike Haertel) (12/13/88)
In article <5077@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >By the way, if you took the one-function-per-program philosophy too far, >you would have separate commands such as cc-g, cc-O, cc-ld, cc-E, etc., >instead of having a single front-end called cc that accepts a large >number of switches. Nobody ever said programs should have really only ONE function. But all of a program's options should be related to its main purpose. Cat -v, for example, fails this test, because making nonprinting characters visible has nothing whatever to do with concatenating files. Cat -u is merely cruft. Cat -s is not portable between BSD and System V; on BSD you can replace it with "sed '/^$/d'" and on System V it means about the same as 2>/dev/null. So -s is disposable too. IMHO, cat needs no options. The -g option to compilers, on the other hand, is intimately related to the internals of the compiler, and there is no clean way to make it in a separate program. #ifdef FLAME Just because it is more 'efficient' to combine functionality in one program (is it really? Think of debugging time . . .) doesn't mean you should. Defending something like cat -s? You're nuts. I suppose you want a -t option to cat, to transliterate characters in its output too . . . or maybe a -e option, to expand tabs . . . or . . . #endif -- Mike Haertel mike@wheaties.ai.mit.edu In Hell they run VMS.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/13/88)
In article <859@thor.stolaf.edu> mike@wheaties.ai.mit.edu writes:
...making nonprinting characters visible has nothing whatever to
do with concatenating files.
But the opposite is quite true. A program that makes nonprinting
characters printable should accept multiple filenames.
It's then a trivial step to optionally let it pass through all data
unchanged.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesipeter@ficc.uu.net (Peter da Silva) (12/13/88)
In article <9138@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >What ever happened to the original Unix Philosophy of lots of little > >programs... > In a Macintosh-like environment, the situation is radically different, > because there is no good way to combine independent processes into a > larger unit. > Of course, one useful integrated > application would be a UNIXy shell with pipes and a bunch of basic > UNIXy utilities. So much for the icon interface. For about the 50th time in the past 5 years or so I would like to suggest that someone with a windowing UNIX box consider the possibility of an icon-based pipeline builder. You could even build structures that can't be expressed in sh! /-----\ | GET | - - [ -p s.fred.data ] \-----/ | /-----\ | PGM | - - [ -options ... ] \-----/ | /-----\ | TEE | \-----/ / \ / \ /-----\ /-----\ |SORT | | PGM | - - [ -more_options ... ] \-----/ \-----/ \ / \ / /-----\ |MERGE| - - [ -whatever ] \-----/ | +-----+ |FILE | +-----+ -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
david@sun.com (People say I'm skeptical, but I don't believe them) (12/13/88)
When these tiresome cat -v (-u this time) arguments break out, I always wonder if the command name space the user sees has to map directly to the names of binary files in system directories. If it's easier for the user to remember cat -v then that should be the command typed. If it's easier for the system implementer to write a single purpose program for this function, fine. All you need is an intermediate layer of software (a CLI, or "shell") to map user commands to execution of binary files. Now, does anyone have any experimental evidence as to the optimal size and properties of command and option name spaces? -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
allbery@ncoast.UUCP (Brandon S. Allbery) (12/18/88)
As quoted from <9138@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn ): +--------------- | In a Macintosh-like environment, the situation is radically different, | because there is no good way to combine independent processes into a | larger unit. This frustrates the heck out of me when I'm using those | systems! In such an awful environment, so-called "integrated | applications" with maximal number of imbedded features are practically | required to get the job done. Of course, one useful integrated | application would be a UNIXy shell with pipes and a bunch of basic | UNIXy utilities. So much for the icon interface. +--------------- I still think this can be done; string lines between applications and/or documents (on a Mac, this might be done with, say, option-shift-doubleclick) and as each application is started in this manner, it opens a window into which one types any necessary commands (or use radio buttons, etc. as usual); the last one could be flagged by leaving off the shift or something, then after all commands are configured the pipeline is run. The advantage is that the pipeline can be made visible with lines (or even graphic pipelines!) between the icons of the applications. You could even run it in the background and check on its completeness by seeing when pipelines disappear from between icons! This is, of course, a first approximation. A real system should probably use the fact that a 2-d display allows one to trace multiple paths between programs, so one could (presumably) split a stream at one point, cause different actions to occur on each stream, then recombine them. Among other things. I also won't argue that the scheme outlines above is necessarily the best way to do it; it's just a possibility, and no doubt someone can come up with a better one. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
eirik@tekcrl.TEK.COM (Eirik Fuller) (12/18/88)
In article <5105@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
) ...
) But the opposite is quite true. A program that makes nonprinting
) characters printable should accept multiple filenames.
) ...
By this line of reasoning we can do away with cat altogether. If I
want to concatenate a list of files, I can just
sed -n -e p /etc/passwd /etc/group
By the same reasoning we can eliminate grep; do I understand
correctly that grep got its name from the idiom g/re/p in ed, where
re means regular expression? The intent of implementing grep
separately was that it was a likely thing to do (based on studies of
what people actually did), and as such was worth speeding up.
Nonetheless, I could live without grep if I still had sed.
So, cat -v can either be Yet Another Switch in your favorite kitchen
sink, or you can get by with a simple if slow sed script that does
the same thing.
No, I don't use sed as my login shell :-) Yes, I use cat -v; why?
because it's there ...