Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.os.misc Subject: Re: UNIX vs. the world (again) Message-ID: Date: 24 Jun 91 17:15:52 GMT References: <25791@lanl.gov> <1991Jun16.184815.17898@kithrup.COM> <25855@lanl.gov> <1991Jun20.104642.27164@colorado.edu> <26207@lanl.gov> <1991Jun22.092931.8341@metapro.DIALix.oz.au> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 71 In article flee@cs.psu.edu (Felix Lee) writes: > What happens if you say "cat a > a" or "cat a >> a"? Horrible things, like what happens if you hook the output of your amplifier to the input. > Does "cat -s" squeeze blank but non-empty lines? No such option should exist. > Should you be able to undo "cat -v" with an inverse tool? No such option should exist. > Should the filename "-" mean standard input or is /dev/fd/0 > sufficient? /dev/fd/0 is sufficient. > Does cat buffer I/O? while((nread = read(...)) > 0) write(...); You forgot: How big is the buffer size? At least 64K. > Should cat use mmap()? If so, should not be detectable from the user's standpoint. > How much of a file should it mmap() at a time? If you perform that optimisation, you're responsible for figuring that out. > Does cat preserve record and block boundaries? If it uses the loop above, yes. > Can you say "cat /dev/tape1 > /dev/tape2" to copy a tape? Depends on the largest block in the tape. > How about "cat /dev/disk1 > /dev/disk2"? Yes. > Should cat use a pool of buffers when reading or writing to slow > devices? If so, it should be transparent to the user. > >What more can you expect of a pipe than to allow data to flow from > >one point to another. > Pipes are terrible for communicating structured data. Perhaps rather > than streams of bytes, programs should be passing streams of ASN.1. Streams have problems with structured data... you basically have to impose your own format on the stream. Pipes are nice, but have their limitations. But for script programming I don't know of any better tool. > >UNIX is more of a theology than product. :-) > Quite. Which sect do you belong to? UNIX is an API. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"