Date: Thu, 12 Sep 2002 22:38:40 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: FreeBSD-Questions@FreeBSD.ORG Subject: Re: lpr Job Name Message-ID: <Pine.BSF.4.21.0209122140440.47638-100000@wonkity.com> In-Reply-To: <p05111702b9a6f1c5a0ef@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Sep 2002, Garance A Drosihn wrote: > >There's another issue: lpd doesn't feed the job name to an input > >filter. If the input filter sends the job to another queue, the > >job name is lost. For symmetry, lpd needs to add a -N parameter > >and job name to the parameters it sends to input filters. > > I don't understand what you're saying here, but then I am very > tired and my brain isn't working right. My proposed script does > not do anything with the -J parameter, it merely "sets" the 'N' > value by the trick of using a temporary file with the appropriate > name. > > If input filters screw up the result of my script, then they will > screw up whatever is done to implement -N... Right. It's not the input filter, though, it's lpd. lpd receives a print job. While processing the job, it calls the input filter with a set of parameters: filter-name [-c] -wwidth -llength -iindent -n login -h host acct-file The filter has no way of telling what the original job name was, because lpd doesn't send it. This is fine if the input filter processes the file and then returns it to lpd. If the input filter sends the file to a different printer with lpr, there's no way to recreate the job name. It's gone. For example: a mini-computer system uses its own version of lpr to send a print job to FreeBSD. The job name is DullReport. lpd on the FreeBSD system receives that perfectly; "NDullReport" is in the control file. Now add an input filter that does something elaborate. Let's say it does some heavy text processing on the job and then sends it to another print queue. lpd runs the filter and gives it the parameters listed above. But the original job name isn't passed, so the filter has no way to name the new job appropriately. > >I did hack in a quick -N flag to lpr, and--much to my surprise--it > >worked fine. Haven't looked at lpd yet. > > Er, sorry, I probably did a bad job saying what I wanted to say. I > am the guy who works the most on lpr in freebsd, so I was talking > more about "how would I implement this for the official lpr?". I > did not mean to imply that your proposed change would not work for > what you wanted. Sure. But I'd like the change to be usable by others as well, so my quick hack is more of a test than anything else. I'd like to see a well-implemented version in the real version of lpr. > If you noticed a lot of people who wanted a feature like this, then > we might as well think about doing it for everyone. But before making > any changes to the official source, I wanted to think about it a bit. Of course. There are security implications in lpr being able to change job names, so I made it privileged like the -U flag. And there's the usage issue we talked about before, and probably a bunch of other things. Heck, -N may have already been used somewhere for something else. (It seemed like this would be more appropriate on -hackers, so I posted a message over there before seeing your response here. Sorry about that.) -Warren Block * Rapid City, South Dakota USA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0209122140440.47638-100000>