lpadmin(8) question

Steven M. List itkin at mrspoc.Transact.COM
Wed Jun 6 10:49:30 AEST 1990

bill at twg.bc.ca (Bill Irwin) writes:

>In article <453 at van-bc.UUCP> sl at van-bc.UUCP (Stuart Lynne) writes:
>>Which is what I need to do. I have two different packages that want to
>>install specialized lp destinations with appropriate filters. Can I install
>>both and have lp figure out how multiplex the requests for the two
>>destinations to the one physical printer?
>I  have had this same problem.  I have one printer that is used for  four
>lp destinations.  When jobs are queued to two or more of the destinations
>at  the  same time, you get garbage.  The solution I came up  with  works
>very  well.  It involves adding some lines to the models which will check
>to  see if there is a lock file in place for this physical printer,  wait
>if  there is;  make a lock file if there isn't;  print the job(s);   then
>remove the lock.  I have attached excerpts from one of my models.

The first two (if/then) and last (fi) lines of this loop are unnecessary,
since the "while" would fall out anyway if the file's not there.

>if [ -f /tmp/computer.lock ]
>        while [ -f /tmp/computer.lock ]
>        do
>                sleep 60
>        done
>touch /tmp/computer.lock

>The  only drawback with this approach that I have encountered is when you
>cancel  a print job the lock is not removed.  You have to remember to "rm
>/tmp/computer.lock" after your cancel, otherwise you next jobs will never

>I  remember  trying to solve this once by trapping the rm  lock  sequence
>inside the model, but it didn't work.  I would be interested in finding a
>better  solution  than this which doesn't force the user to  remember  to
>remove a dead lock file.

If you write the PID or the job ID of the current job in the lock file,
then instead of just checking for existence of the file, you check for
the process or job.  If whatever you're checking for doesn't exist, then
you can remove the lock file.  That way when you cancel, you don't need
to worry about removing the file.
 :                Steven List @ Transact Software, Inc. :^>~                  :
 :           Chairman, Unify User Group of Northern California                :
 :     {apple,coherent,limbo,mips,pyramid,ubvax}!itkin at guinan.Transact.COM    :

More information about the Comp.unix.i386 mailing list