home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sun / admin / 10656 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.2 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!cray.csd.uwm.edu!wls
  2. From: wls@cray.csd.uwm.edu (Bill Stapleton)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: print filter (/etc/printcap : if=) too persistent
  5. Date: 22 Jan 1993 17:04:07 GMT
  6. Organization: Computing Services, U of Wisc-Milwaukee
  7. Lines: 48
  8. Distribution: comp
  9. Message-ID: <1jp9e7INNre@uwm.edu>
  10. References: <PSHANNON.93Jan19131750@iapetus.cv.nrao.edu> <1993Jan21.180848.26090@pwcs.stpaul.gov>
  11. Reply-To: Bill Stapleton <wls@csd4.csd.uwm.edu>
  12. NNTP-Posting-Host: 129.89.6.69
  13.  
  14. In article <1993Jan21.180848.26090@pwcs.stpaul.gov>, derekt@pwcs.stpaul.gov (Derek Terveer) writes:
  15. > I ran into the same problem before, and i agree that lpd seems to be
  16. > out-clevering itself in attempting to optimize its input queue if there
  17. > are jobs waiting at the completion of any particular job.  I never
  18. > really found a solution that was elegant.  I replaced the filter with a
  19. > hand written hack job that looked for various characters, etc. to start
  20. > a new job, but it never really worked 100% of the time.  sigh.
  21.  
  22. That's because you're "out-clevering" yourself assuming "lpd" works in a way
  23. much different from the way it actually works, which is a very much dumber
  24. way with none of the optimization stuff you allude to.  The only way "lpd"
  25. knows which printer a file gets sent to is by what spool directory it's
  26. in.  When you "lpr" a file, the printer name is used to find the proper
  27. spool directory, then is essentially thrown away.  The jobs in the directory
  28. have no information about what printer they were sent to.  Similarly, when
  29. "lpd" prints the queue for a printer, it uses the name to find the spool
  30. directory, and tries to make a lock file there. If it can lock the
  31. directory, it prints all of the files it finds there, unlocks, and quits.
  32. If it can't, then another "lpd" must already be printing the files, so it
  33. exits.
  34.  
  35. Now, if you point two different printers to the same spool file, "lpd"
  36. won't even notice.  Which ever printer entry happens to get started first
  37. will print everything in the directory on the printer pointed to by the
  38. entry it started with, including new files that arrive while it's working.
  39. So, if you send a file to printer A, an "lpd" will start for printer A.
  40. If you then send a file to printer B, if the "lpd" for printer A is done,
  41. an "lpd" for printer B will start.  But if the "lpd" for printer A is not
  42. done, the new "lpd" for printer B will exit, the "lpd" for printer A will
  43. find a new file in it's spool directory and print it, on printer A, with no
  44. idea it was really sent to printer B.
  45.  
  46. There's a way to kludge around this problem using two spool directories with
  47. one lock file, but that gets into other problems I won't try to explain.
  48. (like above, printer B still exits, but then printer A needs to start
  49. printer B when it's done).
  50.  
  51. The best way to deal with this problem is to either use the built-in lpr/lpd
  52. flags, or perhaps have some auto-switching program as ":if=" that looks at
  53. the file and runs different filters depending on the input.  Perhaps using
  54. different commands that users call instead of different printer names
  55. (ie instead of "lpr -P text" & "lpr -P ps" use "lprtext" and "lprps" that
  56. do the right thing internally).
  57.  
  58. --
  59. Bill Stapleton
  60.      wls@csd4.csd.uwm.edu
  61.      uwmcsd4!wls
  62.