Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

comp.unix.sco Technical FAQ (7/7)

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]
Archive-Name: comp.unix.sco Technical FAQ 7/7
Posting-Frequency: Monthly (mid month)
Last-modified: Oct 12

comp.unix.sco Technical FAQ 7/7

See reader questions & answers on this topic! - Help others by sharing your knowledge
   Questions and Answers Related to Printing
   FAQ Starting Page
   These FAQS were developed and maintained for years by (Stephen M. Dunn). Steve no longer has the time to
   maintain them, and has asked me to take them over. Please remember the
   debt all of us owe to Steve for his efforts- I myself spent many hours
   learning from these very documents, and I'm sure many of us can say
   similar things.
   Because Steve has not been able to maintain these for a while now,
   some of the information herein is outdated. I am working to correct
   that, but it's a lot to catch up on, so if you spot something, please
   let me know. For the moment, I'm just marking some of it as probably
   being useless; as I have time, I'll check further to be certain before
   I remove anything.
   Suggestion: Use my to find what you
   are looking for.
   What are printer interface scripts?

   Much of the printer information here makes references to "interface
   scripts". Some people call them "printer drivers" (they aren't). These
   scripts are what controls what happens to your print job as it goes to
   the printer.
   The scripts are found in /usr/spool/lp/admins/lp/interfaces (or
   /var/spool/lp/admins/lp/interfaces on modern systems, though the "old"
   path will still work). You will find that each of the printers listed
   by lpstat will have a script here, and the names will be the same as
   the name of the printers.
   Note that if you are using HP JetDirect printers, the script will be
   there, but the actual script you want to modify is in the
   sub-directory "model.orig".
   To make changes to interface scripts permanent, you want to make the
   same changes in the model script that was used to create the printer.
   The model scripts are usually in /usr/spool/lp/model, but it's
   possible for a printer to get its script from anywhere, so it's best
   to check. You can look in /usr/spool/lp/admins/lp/printers where you
   will find a sub-directory for each printer you have. Within that
   sub-directory is the file "configuration", and you can "cat
   configuration" to see where the script originated.
   If you want your script changes to survive upgrades, copy them to a
   new name in /usr/spool/lp/model, and change the configuration file to
   reflect this, either by setting the model in the Printer Manager or by
   directly editing
   [Table of Contents]
   Which Interface script do I use?

   That depends upon both the printers ability to emulate other printers
   and your need for special effects.
   For example, the "dumb" and "standard" interfaces just send along
   characters. They don't know how to make things bold or change fonts;
   they just send out characters. Most dot-matrix and even quite a few
   lasers are quite happy with that, and will produce output that is
   entirely suitable for typical office reports, though perhaps not for
   word processing.
   If you *do* need more control, you simply need to know what the
   printer can emulate, and choose the appropriate interface from that
   knowledge. Almost all printers emulate something, and in the rare case
   where they don't emulate anything useful, you need to get the control
   codes for the features you want from the manual, and then modify some
   other script.
   Of course, that won't help with programs like Word Perfect that
   provide their own drivers and use the interface files only as a means
   of co-existing with other programs using the spooler. In that case,
   you either need to emulate something that Word Perfect or your other
   high level program can understand, or you have to settle for simple,
   no frills output.
   [Table of Contents]
   How do I stop banners from printing?

   You need to edit the file /etc/default/lpd. You need one of the
   following lines:
   For Xenix: BANNERS=0
   For Unix: BANNERS=nobanner
   Note that there are some Unix printer interface scripts which do not
   use /etc/default/lpd, and you must use an option to these to disable
   banners. Also, some Unix printer interface scripts expect the Xenix
   syntax above. Aren't standards wonderful? Should you encounter one of
   these, if you're reasonably adept at shell scripts, you might want to
   cut and paste the section that reads /etc/default/lpd from a script
   that works properly. Of course, be sure you make note of your changes
   so that you can redo them the next time an upgrade replaces your
   printer drivers.
   On Unix systems, *sometimes* setting it to BANNERS=nobanner was the
   supposedly correct thing to do, but not usually.
   Some printer scripts work from default/lpd even now, but some don't,
   and that can be annoying.
   On Release 5, you are supposed to be able to choose Advanced settings
   from the Printer Configuration manager, and set the number of banners
   to 0.
   The problem is that some of the interface scripts that SCO provides
   don't respect or even check the settings in /etc/default/lpd, and
   although most of the modern ones respect the setting from the Printer
   Manager, there are no guarantees. Do try the simple ways first. If you
   have a current version, you should be able to modify this completely
   within the printer manager. But, if that doesn't work (perhaps because
   you have third party scripts) you need to modify the scripts
   You'll need to modify the scripts to take away the banners.
   Unfortunately, there are differences between the scripts, and even
   after that, there is still more work you'll have to do to make the
   changes permanent.
   To begin with, search in the script for "banner=" at the start of the
   line. You can do this in vi by typing "/^banner=" and pressing enter.
   If you find nothing, try "/^nobanner=". If you still find nothing, try
   Most of the scripts will say :
   On these, you want to change the "yes" to "no". But watch out: some
   scripts (the HPLaserJet for example) need it to be
   You need to read more of the script to see if that is the case.
   Unfortunately, some scripts say:
   and on these, of course, you must change "no" to "yes".
   A few scripts might have:
   This, of course, requires a change to "no".
   Some scripts expect that a variable will be passed to them in the
   environment. These generally test something like this:
   if [ -z "${BANNERS}" ]

   For these, you'd set "nhead=0" after this section of the script. You
   should also be able to accomplish this from the SCO 5 print manager by
   setting the BANNERS setting to 0, but editing the script is absolute.
   Some of the scripts are really dumb about all of this.
   It is entirely possible that you may have a script that does not use
   any such variables, but just blindly prints headers and or trailers.
   In such cases, you need to find where it's doing the printing and
   comment out those lines by putting a "#" ahead of them. If you are not
   sure what to comment out, you might be better off replacing this
   script with something more user friendly from /usr/spool/lp/model. Be
   sure to make a safe copy first, though. Having unwanted banners is
   better than not printing at all.
   LPD printers are another story all together. Roberto Zini offers the

   We had a customer who was lazy enaugh not to specify the
   'nobanner' option along with the lp(C) command: for every
   print job submitted a banner page got printed too and the
   customer was not pretty happy about it (he already tried by
   inserting the "BANNERS=nobanner" parameter in /etc/default/lpd
   but unsuccesfully.

   By following the printcap(SFF) manual pages, he inserted the
   'sh' parameter in the line remote printer line: that should
   tell lp(C) to add the 'nobanner' option on its command line
   but it didn't work. So, to ease his pain, I wrote the following
   lp "wrapper" script, which actually did the job:

   === cut here ===

   # Faked lp(C) frontend to fool the lp(C) subsystem when
   # it's unable to process the 'sh' flag in the /etc/printcap file.
   # This file should be placed under /usr/bin and replaces the
   # original lp(C) file which gets renamed as lp.orig; please
   # set this script permissions accordingly to the original
   # lp(C) ones.
   # (chmod 2111 lp)
   # R.Zini - Strhold (22/03/2000)

   MLPDEF=`lpstat -d | awk '{ print $4 }'`

   # Grab the '-d <printer>' option; if it's not given, use the
   # the DEFAULT destination printer.

   while getopts :d: a
        case $a in
                d)      MYPRT=$OPTARG;;

   # Do we have to use the default printer ?

   if [ "Z$MYPRT" = "Z" ]
        MYDEF="-d $MYPRT "

   # Check if we have to give the '-onobanner' option;
   # in the /etc/printcap file the administrator has to insert
   # the 'sh' flag for this trick to work.

   grep ":rp=$MYPRT:" /etc/printcap | grep "sh" 1>/dev/null 2>&1 && MYBAN=1

   if [ $MYBAN -eq 1 ]
        exec lp.orig $MYDEF -onobanner $MYOPTS
        exec lp.orig $MYDEF $MYOPTS

   === cut here ===

   It's a "quick & dirty" script and perhaps it should be
   rewritten by making use of a more consistent style
   (I'm not that good at shell programming) but I've
   been told that it suited my customer's needs.

   See also
   [Table of Contents]
   Print jobs fail, and I get mail complaining "tcgetattr failed: No such device"

   This is caused by an "stty" line in the interface script for a printer
   that is not connected to a serial or parallel port. Remove the line or
   use a different interface script.
   [Table of Contents]
   Why does printed output garble or stop after several pages?

   This is flow control. The computer and the printer have not made the
   proper arrangements so that the computer can know when to pause to let
   the printer catch up. You aren't likely to see this problem on
   parallel printers, though a bad cable can do this.
   There are two choices for flow control: software or hardware. Software
   flow control is often referred to as XON or XON/XOFF, and you may see
   hardware flow control referred to as "ctsflow" or sometimes "dtrflow".
   Under high speed conditions, hardware flow control is preferred, but
   you do need to know HOW the printer should be wired to set this up, so
   software flow control is simpler.
   The purpose of flow control is so that the printer can tell the
   computer that it is momentarily overwhelmed, cannot handle any more
   input right now, and the computer should suspend sending data until
   the printer notifies it that it is once again ready to receive data.
   If the computer and the printer do not agree on flow control, you will
   lose data. Whether or not the printer notifies you that this has
   happened is entirely up to the designer of the printer, so HP laser
   printers, for example. will display an error message on their front
   panel, but many other printers simply throw away data.
   Most printers don't rely entirely on flow control. They usually also
   have a buffer that fills up with incoming data and gets emptied as it
   prints. If the buffer is larger than the print job, no flow control is
   necessarily needed. That's why small jobs print OK, but larger jobs
   may not- when the buffer fills, the printer needs to yell "Stop".
   As the computer sending the data might not respond instantly to that
   request, the printer has a "high water mark" for the buffer. It might,
   for example, send the "Stop" signal when the buffer is 90% full. Some
   printers let you control that high-water mark. If yours does, setting
   it lower could help.
   But by default, the Operating System provides NO flow control on a
   serial port. If nothing else has been done, a serial port will default
   to 9600 baud, 8 bit, no parity, and NO flow control.
   The very first thing you want to do is DISABLE the serial port
   (example: "disable tty1a"). This may be confusing because you ENABLE a
   printer attached to a port, but you never, never want a printer port
   itself enabled for login. To be safe, check the upper case version of
   the port also ("disable tty1A").
   Many intelligent serial ports (Digiboard, Equinox, Computone, Maxpeed)
   have ways to set and keep serial parameters on their ports. For
   example, if you have a Digiboard, you can type
   "ditty /dev/ttyb02 9600 ixon printer"
   to force the port to stay at 9600 with software flow control.
   However, for the standard com ports (tty1a, tty2a), it's not as easy,
   and you need what's called a "hold-open" script.
   The problem is that while intelligent serial boards have special
   commands to set flow control and keep it set, the standard Unix stty
   command doesn't work that way. To set any option, you have to "open"
   the port, which is simply done by combining the stty command with a
   redirection symbol:

 stty ixon < /dev/tty1a

   Technically, this command actually works, but the problem is that the
   port will be reset to defaults -ixon the instant that the port is
   "closed", and that happens just microseconds after you press return!
   So, effectively, it does nothing.
   SCO technical articles suggest the following command:
 ( stty 9600 ixon -ixany ; while : ; do sleep 3600; done ) < /dev/tty1a &

   The 9600 is the baud rate, and could be different, and of course your
   printer might be on a different port. You need to put this in a
   startup script so that it will run on each reboot.
   Also see Jeff Liebermann's Serial Printing article and
   [Table of Contents]
   Why do I lose the last few lines of my print job?

   This shouldn't happen on modern Unixes, but if you do have this, you
   can try adding "sleep 30" (or even longer) at the very end of the
   interface script.
   The problem in older kernels was that the script would end before all
   the output had been sent out through the driver. The kernel would see
   that that no process was using that data, so it would flush it away.
   Adding the "sleep" keeps the script from exiting, hopefully long
   enough for all the data to get out. If not, increase it. Note that
   this doesn't cause you to wait longer for anything in the printing
   process if the sleep time is equal to the time it takes to print the
   last page.
   [Table of Contents]
   Large print jobs fail on remote printers

   This is a silly artifact from the days when printing was expensive.
   The "mx" setting in /etc/printcap determines how large a print job can
   be, and if there is no "mx" then it sets the size very small. Add
   "mx#0" to have unlimited size. Just stick it in (between :'s) with the
   other stuff.
   [Table of Contents]
   What are the escape sequences to select the trays on my HP printer?

   Back before the dinosaurs died, printers came with manuals that had
   all this stuff in them. Nowadays, you are lucky if it's on the CD, and
   if it is, good luck finding it. Here's a few that may help:
   Hexadecimal Code Decimal Code Octal Code Action
   1B 11 27 17 033 021 Standard Tray
   1B 15 27 21 033 025 (4050) Standard Tray
   1B 14 27 20 033 024 MP Paper Tray
   1B 15 27 21 033 025 500 Sheet Tray
   1B 18 27 24 033 030 (4050) 500 Sheet Tray
   1B 16 27 22 033 026 Optional Envelope Feeder
   The octal codes are what you'd probably use in an interface script:
   echo "\033\030\c"

   Thanks to Jean-Pierre Radley and Richard Seeder
   [Table of Contents]
   How can I print from Netscape without a Postscript printer?

   If you don't have a Postscript printer, you might be able to use
   Ghostscript (available from SCO's Skunkware Page ) to get some
   functionality. Ghostscript is slow and has had a few problems now and
   then, but you might find that you can live with it.
   You can install ghostscript from the Skunkware CD; don't forget that
   you also need the Glib (Graphics Library) package.
   To see the printers that ghostscript supports, type
   gs -?

   You may have to experiment a bit to find out what works best with your
   printer; for example I found that "ljet4" was good for my LaserJet 6L.
   I suggest that you create a simple Postscript file for testing:

   echo "testing" | text2post > /tmp/

   so that you don't get page after page of junk if your first try
   doesn't work.
   My script looks like this:
   /usr/local/bin/gs -q -sDEVICE=ljet4 -r600 -sPAPERSIZE=letter -dNOPAUSE -dSAFER
   -sOutputFile="-" - | lp -dlaser -o raw

   I call that "webprint", and once you've told Netscape to use it
   instead of "lp",that's what continues to pop up in the Netscape print
   Or, you can get fancy and build gs support into your interface script,
   even to the point of automatically recognizing Postscript files. That
   can be a little tricky, and really has no advantage over the shell
   script, but some people like to do it that way.
   [Table of Contents]
   How can I make a device that will print to a network printer?

   First, are you really sure you need to do this? Only very lame
   software can't handle a spooled printer. However, if you must:
   The basic concept is to create a named pipe. For example, you might do

   mknod /dev/myfakenetprint p

   That creates a "device" that your application can print to. Use
   "chmod" as necessary to give it whatever permissions you need (666 if
   everyone needs to use it).
   Now you need something that runs all the time in background. It's a
   shell script (see New to Unix if you don't know how to make a shell
   script) and it needs to start automatically whenever the machine is
   rebooted (see Automating Program Startup). This script assumes that
   your network printer already exists in the spooler:

   while true
   cat /dev/myfakenetprint | lp -dmyrealnetprinter

   You could also use hpnpf or netcat (see Network Printing ) directly:
   while true
   cat /dev/myfakenetprint | netcat -h printername -p 3001

   These work because the "cat" will hang until something (your
   application) writes data to the named pipe. The "lp" won't complete
   until cat is done reading, which will be when your application closes
   its writing. Although it might look like this ties up your cpu, it
   doesn't- the cat sleeps while it hangs, and so does lp or netcat:
   there's nothing going on until you write data to the named pipe.
   [Table of Contents]
   How do I stop extra form feeds that spit out blank pages?

   The concept here is the same as for getting rid of banners and
   trailers, but the scripts are even less standardized. The best place
   to look is in the section that (usually) starts with:
   for file in $files
   Following that maybe a line that does:
   echo "\f"
   or perhaps:
   echo "\014"
   or (less likely):
   echo "^L"
   and sometimes something obvious like:
   echo "$formfeed"
   Your job is to stop that formfeed from echoing. Some of the more
   complex scripts even have a whole separate formfeed program that they
   call. Whatever it is, if it's controlled by a variable set earlier in
   the script (most scripts are this way, including the Laserjet
   scripts), you should change that variable.
   Remember that HP Jet Direct printers have the real script in
   model.orig (see the first section of this article) and that you need
   to modify the models if the change is to be safely permanent.
   Examples: the "dumb" and "hp" models have this code around line 100:
        for file in $files
                0<${file} eval ${FILTER} 2>&1
                echo "\014\c"

   You'd need to remove the "echo "\014\c" line, or comment it out:

              # echo "\014\c"

   There's another "echo" a few lines above; this is the one that spits
   out before your print job.
   However, in the "standard" model, you'll find this around line 289:

   Just as you would change "nobanner" to "yes" to stop banners, you
   change "nofilebreak" to "yes" to prevent extra blank pages. Hans
   Fuller ( reminds me that if an HP script isn't
   already doing an echo "\033E\c" , you should replace the "\f\c" with
   that to reset the printer.
   [Table of Contents]
   How do I make a printer send a form feed at the end of the job?

   Sometimes people complain of the opposite problem: they want form
   feeds and aren't getting them. The answer for this is just the
   opposite of what was covered above: either add "\f" at an appropriate
   place or, if the interface has settings for filebreaks, use that.
   [Table of Contents]
   How do I stop a print job and restart it from the beginning?

   When pages jam, it is sometimes a major job to re-print the job.
   Fortunately, it's pretty simple to starts a job over if it has not
   already all spooled into the printer's buffer.
   The very first thing to do is turn the printer OFF-LINE. That's
   usually done with a ON-LINE or SELECT button.
   Now type "disable printer", or "disable hallway", or whatever the name
   of your printer is.
   Now turn the printer OFF. This will flush out whatever is in it's
   buffer. Turn it back on, and adjust the top of form on tractor feed
   models if necessary. Finally, "enable printer", again, using the name
   of your printer.
   (If you don't know the name, "lpstat -t | more" should help you).
   [Table of Contents]
   How can I get the file from the print spooler before it prints?

   Sometimes you want the results of a print job so that you can e-mail
   it to someone else, import it into a Word Processing document or
   whatever. This is simple to do.
   Put the printer OFF-LINE as described above. Alternately, if you have
   not yet printed, "disable" the printer (see above). Now

 cd /usr/spool/lp/temp
 l [0-9]*-* | more

   You will see something like this:
 rw-rw---- 1 lp  lp   71 Dec 1 09:15 178-0
 rw-rw---- 1 lp  lp   83        Dec 1 09:16 179-0
 rw-rw---- 1 lp  lp 7809 Dec 1 09:15 179-1

   Your dates and sizes will be different, as will the names of the
   These files are information about what is to be printed and how. For
   example, if you looked at that 178-0 file on my machine, you'd find it

 C 1
 D myprinter
 F /etc/passwd
 P 20
 t simple
 U root
 s   0000
 l C_C.C
 m C_C.C

   while the 179-0 had this in it:
 C 1
 D myprinter
 F /usr/spool/lp/temp/179-1
 P 20
 t simple
 U root
 s   0000
 l C_C.C
 m C_C.C

   Notice the difference between the two. You might have already guessed
   that the "C" line is the number of copies, the "D" is the printer it's
   going to print on, and the "U" is the user who printed it. The "F" is
   the file that will be printed, and if it was generated as the result
   of program output (as opposed to "lp /etc/termcap"), it will refer to
   another file in this directory.
   If you have more than one print job, you might not know which file is
   the one you want. If the size of the -1 files combined with the
   destination and user isn't enough to help you, then examine each -1
   file in turn. Once you have what you want, copy the file wherever you
   want it. If you don't want it to print after that, cancel it. For
   example, I might say:

 cp /usr/spool/lp/temp/179-1 /tmp/printfile
 cancel myprinter-179

   [Table of Contents]
   What is a virtual printer?

   You can have a printer that sends its output to another printer; pipe
   the final output to lp -s -dotherprinter You'll probably want the
   first printer's device to be /dev/null, but consider that it does not
   have to be: you can have a printer that prints to multiple places at
   the same time.
   This scheme can be very useful for network printers that use lpd.
   Rather than trying to pass options through, front end with a script
   that does whatever needs to be done (like running it through
   /usr/lib/lponlcr) and then passes it to the lpd printer.
   This is how you do "virtual" printers: many names all going to the
   same print device, but all with diferent options. This is often easier
   than handling all the testing for different switches inside one
   interface, and it gives you mnemonic names like "HPLandscape",
   "HPLetterTray", etc.
   The easiest model to use for that is the "network" script. Let's say
   you want to actually send to "kyocera":

 cp /usr/spool/lp/model/network
 vi /usr/spool/lp/model/yourscript
 (add whatever you need and then)
 /usr/lib/lpadmin -p wrapit -m yourscript -v /dev/null
 /usr/lib/accept wrapit
 enable wrapit
 echo "wrapit: lp -dkyocera" >> /usr/spool/lp/remote

   Now when you print to "wrapit", it will go to the kyocera carrying
   whatever you added in the script.
   [Table of Contents]
   How can different users have different default printers?

   Sometimes you want a person's default printer to be different than
   someone else's (the default printer is the one that gets used when you
   just use "lp" by itself). One way to control that is with LPDEST. For
   example, the following lines in .profile will set the default
   differently when logging in on different tty's:

 DEFPRINT=`tty | sed 's/.dev.tty//'
 LPDEST=biglaser; export LPDEST
 case $DEFPRINT in
   A0[1-8]) LPDEST=printer_7;;
   A09) LPDEST=accounting;;
   0[1-9]) LPDEST=console_laser;;
   B*) LPDEST=ohio;;
   C*) LPDEST=california;;

   This assumes that the port being used determines the persons physical
   location. Sometimes you need to be even trickier than that, or you
   want to change multiple "printers" at the same time. Consider the case
   where you have multiple offices, but you want to have your software
   just use "checks" and "forms" so that the choices it presents aren't
   cluttered with entries like "la_forms", "denver_checks", etc. To do
   this, you need to front-end the lp program itself- you have a script
   that pretends to be "lp", but it decides where the job should really
   go and passes that to the real "lp" program. When it saw a request to
   print to "forms", it would decide what real printer to send to, and
   re-route it appropriately. Here's a post from Bill Vermillion
   describing a similar idea:

 Newsgroups: comp.unix.sco.misc
 From: Bill Campbell <>
 Subject: Re: How do I set default printers?
 Content-Type: text/plain; charset=us-ascii
 Organization: [resent by] The SCOMSC gateway and Propagation Society
 Date: Fri, 28 Apr 2000 18:17:50 GMT
 Message-ID: <>
 Mime-Version: 1.0
 In-Reply-To: <>; from on Fri, Apr 28, 2000 at 10:52:04AM -0700
 References: <nYhO4.9849$> <yJjO4.10289$9A6.56> <>
 Sender: ( News Administrator)
 Precedence: list
 Lines: 55
 Xref: comp.unix.sco.misc:59126
 X-Mozilla-Status: 8010
 X-Mozilla-Status2: 00000000

 On Fri, Apr 28, 2000 at 10:52:04AM -0700, Jeff Liebermann wrote:
 >On Fri, 28 Apr 2000 17:18:22 GMT, "jmt" <> wrote:
 >>I forgotten to mention if the running application has the printer name
 >>hardcoded into there application to which printer to print to, how can I
 >>change that printer? I know what the printer name is, just need to redirect
 >>there print job to another printer name.
 >If your unspecified application has something like:
 >      lp -d printer_name
 >imbedded in some configuration file, then you're stuck.  It takes priority
 >over $LPDEST and over the print spoolers default printer.
 >However, I know of no application, written by mortals, that cannot be
 >twisted into doing what I want it to do.  First, find the configuration file
 >that goes with your unspecified application, and see if you can find the
 >place where the printer is defined.  If it looks like:

 I have a system that does exactly that.  I have a file, /etc/printers
 that has entries mapping logical printer names to real printer names,
 and the system on which to print them.  The file looks like this:

 default        laser localhost
 laser  laser localhost
 oldprn printer someotherhost

 I then have /usr/local/bin/lp that's in the PATH before /usr/bin/lp
 and further I move the original /usr/bin/lp to /usr/bin/lp.original,
 and link it to /usr/local/bin/lp to make sure that everybody uses it.
 My script then reads the /etc/printers file, and maps the printer name
 to the real printer.  If the printer's local, then it forwards the job
 to the local with a pipe to ``/usr/bin/lp.original -ddestination''.
 If it's a different system, then it pipes to the remote system using:

        "|ssh someotherhost /usr/local/bin/lp @ARGV"

 This is in perl so it passes the appropriate arguments to the remote
 system's /usr/local/bin/lp program which goes through exactly the same
 process.  It would even be possible to have the job get in a loop if
 each system redirected the job to the other (I suppose this could be
 done intentionally if there were a printer problem, breaking the loop
 when the printer was working again :-).

   The code you use to decide where to re-route can be as simple or as
   complex as you need it to be. It can be based on the serial port, or
   you could have exported an environment variable. You might even need
   to ask the user in their .profile which "set" of printers they want to
   use, or where they are presently located. Store that information in a
   variable and export it.
   [Table of Contents]
   How do I stop staircase output on the printer?

   Staircase is when you printer prints like this:
 Everything starts out OK, but when you reach
                                              the end of a line, it moves
   but not back

   This is caused by the different ways that DOS and Unix handle the end
   of a text line. Unix ends a line with a LF (Line Feed, 0x0A)
   character, while DOS uses both a LF and a CR (Carriage Return, 0x0D).
   If a printer is expecting both characters, getting only a LF tells it
   to only do a Line Feed without a Carriage Return, so that's just what
   it does, and that's just what you get.
   There are at least five ways to fix this:
     * Change the printer so that it generates a CR when it gets a line
       feed. Most printers can do this, and if you use it for DOS, it
       just means there is an "extra" CR, which changes nothing. This is
       done with dip switches or a printer configuration panel.
     * Change the printer by sending it whatever escape sequences it
       needs to add CR's to LF's. This is going to vary, and you are
       going to need to add it in the interface script low enough that it
       doesn't get reset by some other command being sent out.
     * Set the "stty onlcr opost" in the interface script. This can be
       done from the printer manager on Release 4 and 5, or by using the
       "crnlmap" model; unfortunately it does not always work (for
       example, it can't work for network printers). See:
     * Move the "stty onlcr opost" to a "hold-open" script (see the
       article on serial printers) for this port. This works, but it's
       annoying, and again won't work for network printers.
     * Filter the output through /usr/lib/lponlcr. This involves piping
       the output through that on it's way out. In the "standard" script,
       you might set "FILTER=/usr/lib/lponlcr". In other scripts, just
       add " | /usr/lib/lponlcr" on the line that cats the file.
     * If you are using an HP network printer, you can add "-n" or even
       "-N" to the the interface.
       Don't add it to the "HPNPF=" line; add it in the line(s) that
       actually uses $HPNPF. For example, you'd change

     if $REALMODEL "$@" | $HPNPF -x $PERIPH 2> $LOG > /dev/null
     if $REALMODEL "$@" | $HPNPF -x $PERIPH -n 2> $LOG > /dev/null

       See man hpnpf
   David DiPieto offered these thoughts:
 Date: Tue, 29 Dec 1998 16:05:40 -0500
 From: David DiPietro <>
 Subject: printer stairstepping ...
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit

 I thought I'd share a little opost experience with you.  When I install
 our application software I automatically add a "holdopen" for each
 parallel and serial printer to append the <cr> to <lf> as you mention in
 your printer discussion.  Most of our sites now involve some kind of
 networking and printer sharing.  I had been putting the high-speed
 lasers on the parallel ports on the SCO Unix server but starting having
 a problem with Windows applications printing graphics.  I would often
 loose data or get garbled graphics.  I finally decided to take the time
 to figure out what was going on using the hex dump mode on a Lexmark
 Laser.  Apparently, and with understanding, having opost onlcr turned on
 will do a straight binary filter of the printer data replacing all <nl>
 with <cr><nl> - even if it occurs in the middle of a raster graphics
 string.  This could - and will most likely - reak havoc on the output!
 You may want to address this in your discussion.  In my case, the
 problem was solved completely by turning on the auto <cr> at the
 Dave DiPietro/Abacus Systems Inc.
 (973) 875-9900

   [Table of Contents]
   My printer doesn't work at all!

   The first test is whether or not you can print to the raw device (if
   this is a network printer, see Network Printers). If you aren't sure
   about how the printer handles line feeds, do this:

 /usr/lib/lponlcr > /dev/lp0

   (assuming that your printer is /dev/lp0, of course). Type a few lines,
   and then press enter and CTRL-D. If it gets to the printer, then the
   port is fine.
   The port does show up in "hwconfig", doesn't it? Type "hwconfig | grep
   parallel" or "grep serial" just to be sure. If it doesn't, you either
   never defined it (run "mkdev serial" or "mkdev parallel") or the
   definition is wrong: for example, you said it's a parallel port at
   378, but it's actually at 278.
   If this is a parallel printer, be sure that your BIOS has it set to
   "Standard Parallel Port" (sometimes it's "SPP"). If it's EPP, it will
   not work with current SCO Unix.
   Similarly, there are some "Windows Only" printers that require EPP
   ports and Windows software- those just are not going to work, period.
   See Windows Printers for one way around this. 
   Note : Okidata serial printers require DSR Invalid when using 3 wire
   xon/xoff flow control. Set this on the printer, using the front panel
   If it just hangs, the interrupt is wrong or the card just plain
   doesn't work (and no, "it works in DOS" doesn't help). It's probably
   an interrupt problem; the port is never acknowledging receipt of
   characters so it hangs.
   Understand that the "vec=" info in hwconfig for non pnp devices is
   just a parroting of what YOU told the machine the interrupt is. The lp
   or serial driver trusts you, but it doesn't really have a clue. It
   checks the address (378, etc.) by poking certain patterns into certain
   offsets and then reading the results; if the results are what a
   parallel or serial port should be sending, then it assumes it has a
   working port (see if
   you really want to know the gory details). Whether or not the port
   works otherwise is not the job of the initialization routine, and it
   definitely is not going to check that interrupts are working or even
   Of course, you could have a bad cable, or even a bad printer. I had a
   customer recently who spend half of a day being very frustrated after
   an upgrade because he'd done everything right, had double and triple
   checked everything, but one printer wouldn't print. I suggested
   putting another printer in, and, yep, that was it: a printer that
   worked fine the day before had coincidentally died.
   Check power, too: I once had a printer that would turn on; the panel
   lights worked and all that, but it wouldn't print. It turned out that
   we had only 80 volts at the outlet, and it wasn't enough to drive the
   motors (this was some years ago).
   [Table of Contents]
   Can I use "Windows" printers?

   You could also use Visionfs or Samba, but there are now Windows
   printers that require Windows software and those won't work even that
   way. These are generally less expensive units, and won't mention Dos
   or Macintosh or anything but Windows in their descriptions. At this
   moment, I don't know any way to have these work on Unix, but I did
   receive a great suggestion on this:

 Date: Tue, 29 Dec 1998 16:05:40 -0500
 From: David DiPietro <>
 Organization: Abacus Systems Inc
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit

 I was looking for a solution to an lpstat hang problem in SCO unix with
 TCP based printer server and I noticed you have a remark that you could
 not get the "cheapo" windows printers to work from Unix.  I had a
 conversation with an engineer at Lexmark recently about this.
 Apparently, due to some quirk in the HP PCL licensing agreements,
 printer manufacturers must pay HP a royalty if they use PCL code in the
 printer firmware.  If they use an emulation in the driver, however, they
 do not have to pay the royalty.  So, manufacturers like Lexmark and
 Cannon have developed their own machine language to communicate between
 windows and the printer.  The windows driver converts the HP PCL
 commands to their own machine language and uses that to drive the
 printer.  Since the driver is specific to windows, the printer will not
 work under any other operating system - including DOS.  A sure fire way
 to check is to boot the machine to DOS and try a print-screen.  Note
 that if you shell to DOS it will still print because the windows print
 manager is still resident.  All this to save a few bucks!

 I did find a way around this using a shared drive and an emulator that
 lets you submit DOS commands from the Unix host.  We use a product from
 April Designs in Sweden called Fusion95 to take the place of Advanced
 File and Printer Server, and an emulator called ANITA from the same
 company.  If you have never seen these products, check out APRIL.SE -
 they have 30 day trial versions available for download.

 The way I get this to work is by modifying the standard or dumb model to
 put the output in a shared directory on the server.  When the file is
 done spooling, I issue a DOS COPY command to the emulator to COPY the
 file to the printer port.  Since windows is active, the print manager
 picks up the file and does the proper translation to machine code before
 sending it to the printer.

 In the real world, I do not recommend that our users buy these host
 based printers to use with Unix.  It would cost us more to support them
 than the printers are worth.  With REAL laser's coming down in price,
 why bother!

 I hope I was able to provide you with some information you didn't
 already have!

 Happy Holidays,
 David DiPietro/Abacus Systems Inc.
 Sussex, NJ  (973) 875-9900

   [Table of Contents]
   My printer faults and prints same document over and over

   The only time I've seen this happen is when some very old interface
   scripts were copied up to a new version. I never took the time to look
   at the scripts to see why they weren't working, but apparently they'd
   hang for some reason, so lp would assume a printer fault, stop the
   job, wait a bit, and then send it again. And again, and again..
   Replacing the interfaces with current versions fixed it instantly.
   [Table of Contents]
   Mixing Synchronics and Realworld or other mixed marriages

   Sometimes mixing more than one program causes printer grief because
   one program adds form feeds to its reports and the other does not, so
   you have a nasty problem. It's usually not all that hard to fix,
   though; here's what I did for one customer with that problem:
   Synchronics spooled printers are defined in the "synsuppl" file in the
   Synchronics directory (/syn on ssirw1). These take the form of:

 dd_printername="lp -s -dhpjet5"; export dd_printername

   What I did was add "-o syn" to each line:
 dd_printername="lp -s -o syn -dhpjet5"; export

   Next, I modified the interface scripts. For the hpjet printers, these
   are found in the directory
   /usr/spool/lp/admins/lp/interfaces/model.orig/ Each file there is the
   script that print jobs are processed by. Within the scripts, the
   options are extracted by a section that begins:

 for i in $5
        case "$i" in

        -postscript | postscript)

   I added a test for "syn" to this:
 for i in $5
        case "$i" in

                outputmode="raw" ;
                FILTER="sed '$d'";

        -postscript | postscript)

   Therefore the script acts this way ONLY if "-o syn" is used, which
   will only be for Synchronics. Further on in the script, I added a
   section that tests for $SYN being true, and there I set the lines per
   page to 66. Finally, the FILTER setting above deletes the very last
   line of the report, which contains an extra form feed I don't think we
   want. To disable this, just change




   [Table of Contents]
   How do I do Transparent or pass-through printing?

   Many terminals, and just about all terminal emulators, have the
   ability to do "local" printing. It's sometimes called "transparent
   printing" or "pass-through", but the idea is that if the terminal sees
   a special key sequence, it will start sending the data out some other
   port (parallel or serial) until it sees some sequence that tells it to
   In general terms, it's a lousy way to print. If you can possibly do
   this any other way, you'll be much better off.
   If you have an intelligent multiport card serving these terminals, the
   vendor may have provided a way to make this better (still not great,
   but definitely much better). Digiboard, for example, creates
   transparent print devices that match your tty id's- if you have
   terminals /dev/ttyb01 through /dev/ttyb16, you also have /dev/prb01
   through /dev/prb16, and as long as you have told the Digiboard driver
   what escape sequence will start and stop the printing (common terminal
   types like ansi and wyse60 are configurable by name), the driver will
   do a nice job of handling this for you: anything directed at those
   "pr" ports will get printed.
   If you don't have something like this, you use commands like "lprint"
   (SCO OSR5) or you wrap your data in the start-stop sequences yourself.
   [Table of Contents]
   How can I add or remove printers from the command line?

   The "lpadmin" command can add printers without using SCOAdmin:
 /usr/lib/lpadmin -p printer1 -v /dev/lp -m HPLaserJet
 /usr/lib/accept printer1
 enable printer1
 /usr/lib/lpadmin -d printer1

   adds a new printer named "printer1" which prints to the parallel port
   and uses the "HPLaserJet" model. "lpadmin -d" makes it the default

 /usr/lib/lpadmin -x printer1

   removes the printer "printer1".
   There are other options to lpadmin; see the man page.
   Xenix printers can be transferred with a script like this (which
   assumes that the Xenix hierarchy is located under "/xenixsys"):

 cd /xenixsys/usr/spool/lp/member
 for i in *
 # make sure we aren't overwriting an existing model
 if test -r /usr/spool/lp/model/$i
        echo "Model $i already exists"
        cp ../interface/$i /usr/spool/lp/model
        /usr/lib/lpadmin -p $i -v `cat $i` -m $i
        /usr/lib/accept $i
        enable $i

   [Table of Contents]
   Some print jobs from my application fail mysteriously.

   If the application prints temporary files, you may need to change it
   so that it does an "lp -c" rather than just "lp". This forces lp to
   make a copy of the file immediately.
   [Table of Contents]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer: (Tony Lawrence)

Last Update March 27 2014 @ 02:12 PM