Re: Request for review (LPDEST vs PRINTER)

2000-08-03 Thread Christopher Masto

On Wed, Aug 02, 2000 at 09:35:23PM -0400, Garance A Drosihn wrote:
 The other printing-system alternative is LPRng (which people
 can install from ports).  LPRng does add the 'lpstat' command,
 in addition to replacing lpr/lpq/lprm.  And if I am reading
 this code right, it does check LPDEST for all of those commands,
 *-but-* it has PRINTER taking precedence over LPDEST, and not
 the way POSIX (apparently) describes it.

From testing, it appears that you are reading the code correctly.  The
documentation for LPRng, however, indicates for the SysV commands that
LPDEST takes precedence.  It's probably just an oversight.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Request for review (LPDEST vs PRINTER)

2000-08-02 Thread Garance A Drosihn

At 10:39 PM +0100 8/2/00, Mark Ovens wrote:
I originally sent this to -committers but was advised that the
maintainers and -hackers or -current was more appropriate.

I've posted some patches for PR 14682 which include some changes
to the source code for lpr(1), lprm(1) etc.

Could someone review them for me please, especially the C code.

Your comments in the PR included:

 Whilst investigating this problem I found in /usr/bin/lp:
 # Posix 1003.2 compliant print spooler interface.
[snip]
 # Posix says LPDEST gets precedence over PRINTER
 dest=${LPDEST:-${PRINTER:-lp}}
 
 So it would seem that the Right Thing(tm) to do is to make
 the other programs POSIX-compliant by making them honour the
 LPDEST environment variable rather than simply documenting
 the fact that they don't (the manpages need updating to
 reflect this).

Strictly speaking, that is not the right thing to do. POSIX
is talking about the 'lp' command, which is one of the commands
from the SysV-ish printing world.  'lpr' is the BSD-ish print
world, and therefore it is not covered by what POSIX describes
for 'lp'.  These are two different command sets for printing.

The 'lprm' command is also part of the BSD-ish print world.
I do not have a reference for what POSIX says about commands,
but the "Single Unix Specification" has a description of the
'lp' command.  The description for 'lp' does not talk about
the 'lprm' command.  It says the way to cancel print jobs
sent via the 'lp' command is via the 'cancel' command.  It
also talks about using 'lpstat' instead of 'lpq'.

So, strictly speaking, if we wanted POSIX compliance then
we should add 'cancel' and 'lpstat' commands, and have
those commands behave as POSIX describes them.  If POSIX does
also describe the behavior of the 'lprm' or 'lpq' commands,
then we could talk about changing those commands to be
POSIX-compliant.  I would guess that it doesn't have them.

So, that is my off-the-cuff pedantic-mode reaction, which is
not much help in closing the PR...

I don't feel too strongly about this, but in general I'd
rather document that LPDEST is not used by lpr/lpq/lprm,
and maybe later on add cancel/lpstat commands for those
people who are really expecting the "POSIX print system".

The other printing-system alternative is LPRng (which people
can install from ports).  LPRng does add the 'lpstat' command,
in addition to replacing lpr/lpq/lprm.  And if I am reading
this code right, it does check LPDEST for all of those commands,
*-but-* it has PRINTER taking precedence over LPDEST, and not
the way POSIX (apparently) describes it.  If we do add checking
for LPDEST, I would probably have PRINTER continue to take
precedence over LPDEST.  Right now, anyone who *is* setting
both variables must be used to the idea that PRINTER is the
value lpr/lprm/lpq uses, and I do not think we should change
that.

I would also like to see what openbsd and netbsd do for this,
if anything, but I haven't the time right now.

As to your actual C code, it looks like it would work fine, if
we wanted to do that.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message