At 7:42 PM -0700 7/3/00, [EMAIL PROTECTED] wrote:
>garance drosihn wrote:
> > At RPI, the "pretty" name is always the first in the list, and
> > the "short lc" name is always the last one. If this update was
> > picked up, I'd probably have to do something which didn't make
> > that assumption. Not sure what would be best...
>
>I don't think this level of fine choice of printer names for
>reporting is in LPRng, but I have added the :cm= option which
>is a 'Comment' about the printer which provides your 'long name'
>facility.
Well, there is a bit more significance to this issue if lprNG is
used to replace the lpr in freebsd. In that lpr, all messages
will use the first printer name in the list of printer names for
a given queue. For all I know, lprNG also does that, but if not
then this might be a little surprise to some people at switchover.
> > So, I added a 'jf=' entry, which is meant to say "default
> > per-job filter". If it is set, then that value is used for
> > all per-job filters which are not explicitly set in that
> > printcap entry. Furthermore, I export an environment variable
> > which indicates which filter the script is being called for.
> > LPD_SCRIPT is set to values like "standard", "fortran", "dvi",
> > etc.
> >
> > Note that the value given for 'jf=' is (obviously) not used to
> > set a value for 'of='...
>
>The ':filter=' facility is used in LPRng for the same purpose,
>and the actual format is passed as the -F command line option.
I always use environment variables for "new information" passed
to filters. My lpr is used to drive a few filters that I have
no control over, and the last time I added a command-line option
to a filter, I had some irrate people calling me up because their
printer queue died. Ever since that, I've only added things via
environment variables.
(this is not particularly significant to you, of course, I'm just
saying why I do things the way I do).
> > - - -
> > We have something called "printset" files, which a user or administrator
> > can use to set the default printer for lpr, lpq, lprm. If no printer
> > is specified by the user, then 'lpr' (etc) will first check for a
> > "session printset file" (which probably won't make sense outside of
> > RPI), and then a "user printset file", and lastly a "host printset
> > file". This way we have different default printers in different
> > public labs, but the user just types 'lpr' if they want the "right"
> > one (because we've set up /etc/printset files on those machines).
> >
> > Besides defining the "default" printer, these printset files define
> > pseudo-printers called 'PS' and 'COLORPS' (or something like that).
> > So, we can install applications and tell them to print to 'PS' or
> > 'COLORPS', and the user can control where that output will go. We
> > needed this because we had a few X applications early on which were
> > a real headache to change the printer inside the application...
>
>The 'default' printer, 'wildcard' printcaps, and :oh= facilities
>are similar solutions.
>
>For example, if all of the hosts in lab1 have hostnames
> *.lab1.rpi.edu, and lab2 has *.lab2.rpi.edu, then you can have:
>
>ps:oh=*.lab1.rpi.edu:[EMAIL PROTECTED]
>ps:oh=*.lab3.rpi.edu:[EMAIL PROTECTED]
I do not see how these are equivalent. Assuming I understand this,
the only thing this does is the equivalent of /etc/printset. It
does not provide a user-override for "printer PS" (via ~/.printset),
or a session-level override (which I did not fully explain here).
To make this a little clearer, "we" (the computer center) will
configure some X-based monstrosity to use "printer PS". When
users want to change where the output from that program goes,
they use some printset file to change the mapping of PS to the
printer queue that they want. They can change it on a per-session
basis, a per-userid basis, or a hostname basis (if they are the
administrator of that hostname, such as if the host is the machine
in their own office).
> > - - -
> > lpr has a status file it uses to hold information about the
> > status of a given print queue. I have it tack on 'extended'
> > to that filename, and have CAP (or whatever the print filter
> > is) put "extended status" information into that file. 'lpq'
> > will include this "extended status" line if the user specifies
> > 'lpq -l' (long).
>
>???? Puzzled a little on this...
Just a second file which would hold some more-detailed status
information. In the case of CAP (the only filter I have which
currently uses this), it includes the byte-count of how many
bytes have actually been sent to the printer. It actually
includes a little more than that, but that's the only field I
look at in the extended-status line :-) This is useful in the
case where a job seems to be "just sitting there", and you're
wondering if anything is happening. I could also put a running
page-count in here, at least for some of our printer queues,
but I haven't done that yet.
Basically, the extended-status file is updated at a different
point than the status-file, and is only updated by the filter
(ie, it is never updated by lpd itself). Also, the extended
status line is only printed out of the user specified '-l'.
Similarly, I want to add a "pending status" file, which would
only be updated by lpc. I want operators to be able to say
something like:
lpc stop pqueue -msg Need to replace cartridge
Stop will cause the printer queue to stop AFTER the current
job prints, but it does not abort the current job. So, the
above should not change the ACTIVE status file, it should just
remember what the operator wanted, and make that the status
message after the current job completes.
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
-----------------------------------------------------------------------------
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
