HDTenEightyP/NetNews huggingface dataset:
From: john@iastate.edu (John Hascall)
Subject: Re: file system layout
Organization: Iowa State University, Ames, IA
Date: Thu, 31 Dec 1992 16:57:10 GMT

singer@ll.mit.edu (Matthew R. Singer) writes:
}3) Format and mkfs under SunOS.  

}If I were to pre-write a file a Sun disk, is there a simple way to find out
}what blocks on the disk the file system has allocated for it.  Since I 
}am writing just one big file on a newly formatted disk, it should be 
}contiguous (right?).

Not necessarily (probably not).  First, disks are divided into
"cylinder groups".  Second, there is a parameter fs_maxcontig
which limits the number of contiguous blocks.  A more detailed
discussion can be found in `A Fast File System for Unix'.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
From: Dave-Nuttall@cup.portal.com (David Dave Nuttall)
Newsgroups: comp.unix.wizards
Subject: Source Exist?
Date: Tue, 29 Dec 92 14:41:00 PST
Organization: The Portal System (TM)

I recall someone telling me that they had ported  the Xenix "pstat"
towards System V.  (Was it Chip in Austin?)

I would like to obtain source code for the Xenix utilities
"pstat" and "dtype" if they are available in the public domain.
Pls post or e-mail  your comments/suggestions.

Thanks.
Newsgroups: comp.unix.wizards
From: alex@doris.par.univie.ac.at (Alexander Celic)
Subject: How can I turn off the cache on a Hyperecube ???
Organization: University of Vienna
Date: Wed, 23 Dec 1992 04:50:59 GMT


Hi Wizards!!!!

I've got a BIG problem: how can I turn off the cahche (instruction AND data!)
on a Hypercube comtputer? I know this question could sound weird, but this is
the only way I can continue whith my project.

So, if anybody has an idea (or some tool :-) ), I'd be saved !!!!

						THANKS, Alex
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: sh/csh interpretation of backquotes
Date: 21 Dec 92 16:51:16 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec17.174208.28328@mfltd.co.uk>, sml@mfltd.co.uk (Shaun Lowry) writes:

> Can anyone tell me why 
> $ echo `tput bold`
> works in sh and ksh, but not in csh?

Different quoting conventions, probably.  It would really help a lot if
you could tell us what "tput bold" produces, or at *least* what
terminal type you're using.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: jbm@fokus.gmd.de (Joerg Micheel)
Newsgroups: comp.unix.wizards
Subject: Re: a novice unix internals question
Date: 21 Dec 92 17:18:09 GMT
Organization: GMD-Fokus (Berlin)

In article <1992Dec20.225210.9418@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
|> In article <1992Dec16.081648.22123@sbcs.sunysb.edu>, synchem@sbcs.sunysb.edu (Synchem proj acct) writes:
|> 
|> > In the Leffler 4.3BSD Unix book, it was discussed that the run-time
|> > structure of the kernel is divided into a top and a bottom half.
|> > [...]  My question is, which process does the bottom half belong
|> > to[?]
|> 
|> As you guess (in text I deleted), bottom-half routines do not
|> inherently belong to any process.  If they correspond to a device that
|> is being used by only one process, they could be thought of as
|> belonging to that process, but the code is generally not written to
|> correspond to this, and for some devices (eg, disks) it doesn't even
|> really make sense.  There usually is some process current when the
|> bottom half runs, but it bears no relation to anything in particular;
|> it's simply whatever process happened to have the cpu when the
|> interrupt happened.  If the machine isn't busy, it's even reasonably
|> likely that the interrupt happened during the idle loop.  (For example,
|> the bottom half cannot count on any given process being incore.  Some
|> things are kept incore even for swapped processes, like the proc struct
|> in 4.3; these can of course be used once the correct one is found.  But
|> the u area may be swapped....)

I completely agree with you, but have to mention, that the deamon book isn't
as strict as you with these semantics. In particular (page 46) Entry to the
Kernel they say: "When a process enters the kernel trough a system call, a
trap, or an interrupt, the kernel must ....". Aha. So the process currently
running enters the kernel, when an interrupt occurs ?! Yes and no. I guess
that CSRG people were just playing a bit with the term of a process (like:
everybody dealing with these things knows, what happens, so why bother ? ;-).
It's true, that the interrupt thread is completely unrelated to the process
running, but the process get's charged for the time of interrupt processing
(see the statement in kern_clock.c to hardclock()).
I think that things might get clearer, when talking about threads instead
of processes.

Just thoughts ...

Joerg 

-- 
GMD	German National Research Center for Computer Science
FOKUS	Open Communication Systems Research Center
							Berlin, Germany
From: Unix-Wizards@BRL.MIL
Newsgroups: comp.unix.wizards
Subject: >To:
Date: 21 Dec 92 14:53:13 GMT

Date: Mon Dec 21 14:24:51 GMT 1992
Received: from BRL.MIL by tintin.csl.sni.be; Mon, 21 Dec 1992 15:24 MET
Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n3n4T-0000jkC@snibru.uucp>; Mon, 21 Dec 92 14:21 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA29097; Mon, 21 Dec 1992 15:14:47 +0100
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 8859; Mon, 21 Dec 92 08:13:20 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 1671; Mon, 21 Dec 92 08:13:17 CST
Original-Date: Mon, 21 Dec 1992 14:56:49 MET
Original-Subject: SLIP dialer
Not-Delivered-To: tintin!\  due to 12  Inability To Transfer
     ORIGINAL MESSAGE ATTACHED
     (rmail: Error # 21 'Permission denied by /etc/mail/mailsurr file')
End-Of-Header: 
Content-Type: text
Content-Length: 1222

Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n3n4T-0000jkC@snibru.uucp>; Mon, 21 Dec 92 14:21 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA29097; Mon, 21 Dec 1992 15:14:47 +0100
Message-Id: <199212211414.AA29097@ub4b.buug.be>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 8859; Mon, 21 Dec 92 08:13:20 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 1671; Mon, 21 Dec 92 08:13:17 CST
Date:         Mon, 21 Dec 1992 14:56:49 MET
Reply-To: Unix-Wizards@BRL.MIL
From: Lars Hornborg <lasseh@MICROFRONT.SE>
Subject:      SLIP dialer
X-To:         listor@microfront.se
To: Multiple recipients of list UNIX-WIZ <UNIX-WIZ@VM1.NoDak.EDU>
Content-Type: text
Content-Length: 381

I'm looking for a SLIP dialer for DOS. I think I've seen one mentioned
(is it in the Crynwr collection?). Many thanks for any tips you might have.

Happy Holidays,
--
  Lars Hornborg                         Tel: +46-47081065
  Microfront Vaxjo AB                   Fax:        82356
  P G Vejdes vag 15                     Internet: lasseh@microfront.se
  S-352 52  VAXJO
  SWEDEN
From: Dave-Nuttall@cup.portal.com (David Dave Nuttall)
Newsgroups: comp.unix.wizards
Subject: NLIST Discussion
Date: Tue, 29 Dec 92 14:33:21 PST
Organization: The Portal System (TM)

I need to locate reference material which discusses the function
"nlist".  If you have anysuggestions, please post or e-mail me.
From: cq377@cleveland.Freenet.Edu (David C. Williss)
Newsgroups: comp.unix.wizards
Subject: Re: /dev
Date: 23 Dec 1992 05:42:52 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cq377@cleveland.Freenet.Edu (David C. Williss)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, les@chinet.chi.il.us (Leslie Mikesell) says:

>In article <1h57c2INNhsi@chnews.intel.com> bhoughto@sedona.intel.com (Blair P. Houghton) writes:
>
>>>  1.  Should I look at the /etc/printcap file to find printers?
>>
>>Look at the PRINTER environment variable (RTFM getenv(3)),
>>and then check the printcap(5) and use the first printer
>>you find there.  That is, *if* the machine has a printcap
>>(AIX does not; it uses a thing called "qconfig.")
>
>Blatent BSDism here.  SysV(pre-r4) doesn't have printcap or lpr and
>has no convention for a PRINTER variable.  Besides, even if lpr
>and printcap exist on a machine it doesn't automatically mean that
>it's the spooler I want to use.
>
>Les Mikesell
>  les@chinet.chi.il.us 
>
Yes, that's part of my problem.  How do I know which to use.  The same
code must portable and compile on several kinds of unix.  Machines
involved are Data General Aviion, HP Apollo, OKI station (SysV),
Sun (BSD), SGI Iris Indigo, Macintosh Quadra (running AUX), Decstation
5000, and IBM RS/6000 (AIX).  

Thanks for all the suggestions.  popen looks like my best bet.  Unless
somebody can give me advice on how to determine which to use (lp/lpr),
I'll just make it an option.  Then I'll just need to bring up a dialog
for all options.  I'll probably allow an option to print to any 
command so that an expert user can do whatever they want 

Thanks,

	Dave Williss

-- 
		-Dave Williss
---------------------------------------------------------------------------
GAAKK -- It's not just for breakfast anymore!
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: /dev
Date: 22 Dec 92 18:19:54 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1h57c2INNhsi@chnews.intel.com>, bhoughto@sedona.intel.com (Blair P. Houghton) writes:
> In article <1h3m36INNd4l@usenet.INS.CWRU.Edu> cq377@cleveland.Freenet.Edu (David C. Williss) writes:

>>  1.  Should I look at the /etc/printcap file to find printers?
> Look at the PRINTER environment variable (RTFM getenv(3)), and then
> check the printcap(5) and use the first printer you find there.
> Or just use lpr(1).
>> [...]
> [I]f [users] have any normal printers to which your output could go,
> they'll have to have a working printcap,
> Or just use lpr.
>>  2.  How do I print to a remote printer[?]
> Barry says to use popen(3) and lpr.  I say, "What he said."

Really, Blair, I would expect you to know better.

Not everybody even *has* lpr.  Not everybody that has it uses it.

They should let the user specify a command.  They may want to let the
installer specify some common commands so the users don't have to
remember them.

They should *not* hardwire anything, including "lpr", except as a
last-ditch default.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: a novice unix internals question
Date: 31 Dec 1992 23:43:43 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1992Dec21.171809.11037@fokus.gmd.de> jbm@fokus.gmd.de
(Joerg Micheel) writes:
>It's true that the interrupt thread is completely unrelated to the process
>running, but the process gets charged for the time of interrupt processing
>(see the statement in kern_clock.c to hardclock()).

Fixed in 4.4BSD, at least on machines that have a separate hardware timer
(e.g., hp300, sparc, but not i386).  Come to USENIX to hear my talk about
this. :-)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.unix.wizards
From: aj3u@larch.cs.virginia.edu (Asim Jalis)
Subject: Does Unix Guarantee Limits on Delays
Organization: University of Virginia, Charlottesville, VA 22903
Distribution: comp
Date: Fri, 25 Dec 1992 20:24:44 GMT

The problem that I am working with is this.  I want to time the
interval between the occurrence of two mouse events.  I want to
have some confidence in the accuracy of my readings, independent
of the number of other processes running on the system or their
nature.

Does Unix guarantee, either explicitly, or implicitly through the
way it is designed, that a call to the clock daemon will return
within a certain fixed upper limit amount of time?  Possible
sources of delays could be task-switching by the scheduler, or
the clock daemon not responding immediately for some reason;
there might be others that people here could suggest.  Also,
consider the same question but with this time querying about
bounds on the execution of each ordinary instruction.

If Unix does not provide such guarantees then I would like
suggestions on how testing could establish a worst case upper
bound on this delay.  For example, I could have N1 infinite loop
processes running and N2 processes that repeatedly call the clock
daemon and N3 i/o processes etc.  Are there any other classes of
processes that could make a significant difference in how the
scheduler and the clock daemon behave?

Any help would be much appreciated.


Asim Jalis.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.wizards
Subject: Printers (was Re: /dev)
Date: 22 Dec 1992 00:41:33 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1h3m36INNd4l@usenet.INS.CWRU.Edu> cq377@cleveland.Freenet.Edu (David C. Williss) writes:
>  1.  Should I look at the /etc/printcap file to find printers?

Yes.

>      Assuming that somebody at the user's site is compatent
>      (bad assumption) they would just have to setup printcap

If they haven't setup printcap, then they can't use the printers they have
connected to the system.  The fact that your one application can't use the
printers is just a minor component of that problem (unless you're assuming
that they purchased the systems just to run your application).

>      The problems here are 1. Based on past experience, I can't
>      assume they know what their doing.  2. Seems not all flavors
>      of unix use /etc/printcap. (We're supporting multiple platforms)

You'll need to find out what other systems use instead of /etc/printcap,
and conditionalize your code.

>  2.  How do I print to a remote printer.  I suppose I could fork
>      and exec lpr.  Is that the reccomended method?  

Or "lp" on systems that have it instead.  That's usually the correct way to
print to *any* printer.  On many Unix systems, the spooler process opens
the device file permanently, so ordinary processes can't write to it
directly.

You should provide a configuration option to let you change the command
that's used.  Some sites have custom interfaces to printers.

>  3.  For the sake of argument, lets say I ignore printcap and let the
>      user select printer driver/port from within my program.  Is
>      there any way to tell which special files in /dev are ports
>      and which aren't?  Every book I've read talks about "conventional"
>      names, but every implementation seems to have its own ideas
>      as what to name them.  I want to avoid confusing the user by
>      showing such things as /dev/rroot.

I don't think there's any general way to tell.  /dev/tty00 is a terminal if
there's a terminal connected to it, but a printer if there's a printer
connected to it.  There's no way to tell just by looking in /dev -- you
need to look in the machine room.  And network printers don't have any
corresponding name in /dev.  And even if you do determine that a device is
a printer, the name in /dev is unlikely to be meaningful to the user.
Users are used to the names that they can give to the lpr or lp commands,
which might be the type of printer (e.g. "laser"), the location ("lw2" for
the LaserWriter on the 2nd floor), the department name, or some cute name
(we name all our printers after newspapers -- this is so obvious that I'm
sure there are many others).  Showing an unsuspecting use names like "ttya"
or "tty00" is likely to be very confusing.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Does Unix Guarantee Limits on Delays
Date: 31 Dec 1992 23:51:32 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <AJ3U.92Dec25152444@larch.cs.virginia.edu>
aj3u@larch.cs.virginia.edu (Asim Jalis) writes:

>Distribution: comp

(Note: `comp' is not a distribution; it is part of a newsgroup name.  If
your news reader inserts this automatically, bring that to the attention
of your news administrator.)

>The problem that I am working with is this.  I want to time the
>interval between the occurrence of two mouse events. ...
>Does Unix guarantee, either explicitly, or implicitly through the
>way it is designed, that a call to the clock daemon will return
>within a certain fixed upper limit amount of time?

It is not at all clear what you mean by `a call to the clock daemon'.
Moreover, depending on where these times are sampled, and by what
(hardware or software) there could be an arbitrarily large error.  You
will get the best results by having the mouse hardware generate its own
time stamps, to be included with the mouse event data as sent from the
mouse to the receiver (memory, cpu, serial port, whatever).  The next
best timing will arise from sampling the actual time (e.g., using
microtime() under BSD or uniqtime() under SunOS) in the code that is
closest to the `mouse event'.  Typically this is in the interrupt
handler for the mouse.

If you are attempting to measure times from user code, the error (and
the variance in samples) will increase.  Different UNIX systems make
different guarantees (or lack(s) thereof) in response times, both to
interrupts (if indeed they use interrupts at all) and to running user
programs.  For such information, you will have to consult directly with
your vendor.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Xref: sparky comp.unix.wizards:5335 news.answers:4726
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Newsgroups: comp.unix.wizards,news.answers
Subject: Intro to comp.unix.wizards - read before posting! (last change: Mon Nov 30 0:57:50 EST 1992)
Summary: This posting explains the purpose of the comp.unix.wizards
	newsgroup.  It should be read by anyone who wishes to post here.
Date: 25 Dec 92 05:43:14 GMT
Expires: Tue, 23 Feb 1993 05:43:03 GMT
Followup-To: poster
Organization: Rensselaer Polytechnic Institute, Troy NY

Archive-name: unix-faq/wizards-faq
Last-modified: Mon Nov 30 0:57:50 EST 1992

Please take a moment to read this before posting to comp.unix.wizards
for the first time.

comp.unix.wizards is for in-depth discussion of advanced unix topics.

Elementary questions do not belong in comp.unix.wizards.  Although some
socket questions (for example) are appropriate, "How do I program with
sockets?" is not.

Crossposting to comp.unix.wizards and comp.unix.questions is
inappropriate.  Plenty of wizards read comp.unix.questions and answer
questions there.  KILL file users can skip all crossposted articles
with "/Newsgroups:.*,/h:j".

A wizard is someone who can rewrite the entire system from scratch.  If
you are not a wizard, you are welcome to follow along the discussions
anyway.  You'll learn quite a bit about how UNIX works.  Caution: post
to wizards only if you are yourself a wizard.

For a list of answers to frequently asked questions (FAQ), please refer
to comp.unix.questions (or comp.lang.c, news.answers, etc...).  "How do
I delete a file whose name starts with a '-' ?" is an example of such a
question.  Please do not ask or answer FAQ's on the net.

Write to Unix-Wizards-Request@BRL.MIL (Subject: subscribe.  Any
message.) if you want a daily digest of this newsgroup mailed to you.

To unsubscribe from the unix-wizards mailing list, send mail to
"info-unix-cancel@brl.mil", no text required.  It is incorrect to post
such requests to the list, or to mail them to me, though others may
mistakenly do so.

E-mail comments about this posting are welcome.  From time to time I'll
summarize them.

Brian
--
These opinions are mine, and do not necessarily reflect those of any
academic department or computing service at Rensselaer.
Newsgroups: comp.unix.wizards
From: john@iastate.edu (John Hascall)
Subject: Re: NLIST Discussion
Organization: Iowa State University, Ames, IA
Date: Thu, 31 Dec 1992 16:42:47 GMT

Dave-Nuttall@cup.portal.com (David Dave Nuttall) writes:
}I need to locate reference material which discusses the function
}"nlist".  If you have anysuggestions, please post or e-mail me.

The nlist function is really quite simple to use.  Basically all it does is
read the symbols of out a (non-stripped) image.  Your system should have a
"man nlist" and in include file (say, /usr/include/nlist.h) which should
give details.  Here is a fairly simple example of its use:

#include <stdio.h>
#include <nlist.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/fixpoint.h>

struct  nlist Nl[] =			/* an array of the symbols that you */
{					/*   are interested in the value of */
        { "_avenrun" },			/* name of a symbol (_ optional?) */
#define X_AVENRUN       0		/* index of sym (coding convention) */
        { NULL },			/* NULL to terminate the list */
};

/*
 * get load average (most recent) as an integer
 * this version for DECstations which store the load avg as 3 FIXEDPOINTS
 */
int loadavg()
{
        static int      kmfd = -1;	/* file descriptor for /dev/kmem */
        long            avenrun[3];	/* really fixedpoint, look like long */

	/*
	 * To get the value of avenrun we will need to read it from
	 * /dev/kmem (once we find out where it is with the nlist()
	 * function).  Since we get called often lets just open it once.
	 * We also only need get the Nlist once.
	 */
        if (kmfd < 0) {
		/*
		 * Must be the first time through, open /dev/kmem
		 * and mark it close on exec so our child processes
		 * close it when they exec.
		 */
                if ((kmfd = open("/dev/kmem", O_RDONLY, 0)) < 0) return (-1);
                (void)ioctl(kmfd, FIOCLEX, NULL);

		/*
		 * get the Nlist out of /vmunix
		 * (something more clever might allow the name as an arg)
		 */
                nlist("/vmunix", Nl);
        }

	/*
	 * If the first entry of the Nlist array has n_type of 0 (zero)
	 * then it failed (probably because it was stripped).
	 */
        if (Nl[0].n_type == 0) return (-1);

	/*
	 * all is good, Nl[X_AVEBRUN].n_value tells us where to seek
	 * in /dev/kmem to read the current value of the variable
	 * We go ahead and read all 3 entries of the array even though
	 * we'll only use the zeroth.
	 */
        if ((lseek(kmfd, (off_t)Nl[X_AVENRUN].n_value, SEEK_SET) == -1) ||
            (read(kmfd, (char *)avenrun, sizeof(avenrun))) != sizeof(avenrun)) {
                return (-1);
        }
	/*
	 * convert/round it to the form we want (an integer)
	 */
        return ((int)(FIX_TO_DBL(avenrun[0]) + 0.5));
}
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
From: chris@tisdec.tis.tandy.com
Date: 23 Dec 92 10:41 CST
Newsgroups: comp.unix.wizards
Subject: Re: Printers (was Re: /dev)
Message-ID: <51600005@tisdec.tis.tandy.com>
Nf-ID: #R:<1h5o7tINNact@early-bird.think.c:-35:tisdec.tis.tandy.com:51600005:000:894
Nf-From: tisdec.tis.tandy.com!chris    Dec 23 10:41:00 1992


/* Written  5:21 pm  Dec 21, 1992 by les@chinet.UUCP in tisdec.tis.tandy.com:comp.unix.wizards */

>> Blatent BSDism here.  SysV(pre-r4) doesn't have printcap or lpr and
>> has no convention for a PRINTER variable.  Besides, even if lpr
>> and printcap exist on a machine it doesn't automatically mean that
>> it's the spooler I want to use.
>> 
>> Les Mikesell
>>   les@chinet.chi.il.us 

BZZZT.  Pre-r4 SysV systems may not recognize the variable PRINTER, but
lp{,r} does recognize (in most cases) LPDEST, for specifying the USERS
default printer.  The environment variable PRINTER, on SCO anyway, is used
to tell lp{,r} whether to use a local (passthru) printer or the system spooler.

Just trying to get both sides in, and disarm any miss-information.
(Additional corrections welcome)

There are things I like, and dislike about both BSD's and SYSV's print systems.

chris@tisdec.tandy.com