Path: utzoo!utgpu!watmath!att!cbnewsc!gregg From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly) Newsgroups: comp.unix.questions Subject: Re: How does man know? Message-ID: <3586@cbnewsc.ATT.COM> Date: 2 Oct 89 03:30:08 GMT References: <11204@smoke.BRL.MIL> Organization: AT&T Bell Laboratories Lines: 72 From article <11204@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > In article <3559@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >>The best example is printing manual pages. My manual program does >>NOT provide a printing feature. Instead it provides the capability >>to return the path to the manual pages so that nroff/troff/whatever >>can be used to format it. > > Jesus, what's the difference between formatting a manual page to a > terminal and to a printer? Simple, the ".I" (or \fI) font change directive causes underlining in nroff, but italics in troff. If I prefer the italized version, I can get it. My point was that it is rediculous to wire in a printing environment or hook of some sort because it would probably be wrong or not provide all of the information that one needs (like I tried to point out above). UN*X has yet to become the proud owner of a standard printer interface/spooler. > You can't even tell whether I'm using > my terminal window as a port to access an attached printer or not. > I may also be using a Braille terminal, and would disappreciate > pagination. There are far more possible environments than you > can anticipate, which is why you should not hard-wire in limiting > environmental assumptions. Which is precisely why the printing feature is not there... Okay, maybe you don't see where I am comming from. The fact that the program returns you the place where the manual page resides means that you can have a tool (if not your own nroff macro package) format the manual to be compatible with your output device. I thought that the idea that you were pushing earliar was tools should do one thing and then each user can build their own conglomerates to go with the enviroment in which they work. > By catering to obsolete technology as your assumed "common case" > and insisting that better uses of the software will have to be > accommodated by additional programming effort, you're providing a > powerful disincentive to improve the computing environment! I was hoping that someone would say that! Is it not obvious that always relying on the users to build conglomerates (because the original tool was incomplete for the most used case) that are useful is what most people hate most about UN*X. You seem to be saying two things here. First you say use the tool idiology then you say put in the features that promote new technology. Can you clarify where you stand on this, I am confused. How many SYSV users are actually happy that ls(1) does not use -C by default? Does't most everyone that you know have an alias/script/own-version-of-ls.c that does make -C the default (or even like man, add -C when fd-1 is a terminal)? Everyone that I know does! By the time we get through inventing all of our own little customizations to incomplete tools, we can not make use of another UN*X machine without taking timeout to bring our toolkit with us. Frankly I don't like doing that, it wastes my time and disk space. # # Sigh, another solution to a tool that isn't... # # lf.sh # if [ -t 1 ]; then exec /bin/ls -CF "$@" else exec /bin/ls "$@" fi -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)