How does man know?

[gregg.g.wonderly]

>From article <11204 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn):
> In article <3559 at cbnewsc.ATT.COM> gregg at 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 at att.com   (AT&T bell laboratories)