Red Hat Bugzilla – Bug 71650
dvips fails to write to lpr
Last modified: 2007-04-18 12:45:34 EDT
Description of Problem: dvips fails when writing straight to lpr Version-Release number of selected component (if applicable): tetex-dvips-1.0.7-55 How Reproducible: for me, always Steps to Reproduce: 1. run dvips on any dvi file with no additional arguments Actual Results: This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.08.15:2241' -> |lpr dvips: ! couldn't open output pipe Expected Results: dvips should send the output to the default printer Additional Information: dvips file.dvi -o file.ps; lpr file.ps works fine. The only dvips customization I've done is to change the default paper size to letter (instead of a4). I have used dvips file.dvi to send to the default printer since dvips was born. This is the first time this hasn't worked. Unfortunately, dvips is not providing much information as to what is wrong. I would like to dig more into this so I could submit a patch or more detailed information, but I'm trying to get ready to leave on a trip, so this will have to do for now. I'll post more details if I get a chance.
This is probably related to it running securely by default now.
Created attachment 71185 [details] Patch to make '-R0' option work
In theory, 'dvips -R0 file.dvi' ought to work. In practice, '-R0' (to turn off secure mode) seems to be broken. The above patch ought to fix it, but I haven't tested it. Probably there ought to be an example of this command line somewhere prominent too.
In fact, the error message itself would be a good place for that. Also, I wonder if '|lpr' is really a good default output filename. Perhaps it should be changed to output to a <name>.ps.
Since this still exists on null and the topic came up on the list, I've updated the product version from limbo to null.
Updated version to 8.0 since it didn't get fixed for release.
*** Bug 75041 has been marked as a duplicate of this bug. ***
No remark on the use of -R0 in error messages will help. It is because running texconfig, in the dvips config section the testpage does not get printed: Output written on testpage.dvi (1 page, 5904 bytes). Transcript written on testpage.log. This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.10.04:0921' -> |lpr dvips: ! couldn't open output pipe
*** Bug 75731 has been marked as a duplicate of this bug. ***
-R0 not working of course also breaks any execution of \specials. Resulting in "Failure to execute %s; continuing" error message.
I just installed the latest teTeX beta, and dvips works out of the box. $ dvips 2001erdos_abstract This is dvips(k) 5.90a Copyright 2002 Radical Eye Software (www.radicaleye.com)' TeX output 2002.10.13:1940' -> |lpr <texc.pro><8r.enc><texps.pro>. <cmex10.pfb><cmsy7.pfb><cmmi7.pfb><cmr10.pfb> <cmr7.pfb><cmmi10.pfb><cmsy10.pfb>[1]
On redhat-8 + all errata: [bill@octagon bill]$ dvips -R0 nfsroot.dvi This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.10.23:1520' -> |lpr -Pgrad dvips: ! couldn't open output pipe
Yes--read all the above comments, you'll see that we know that -R0 is broken, and there is a patch to try.
While the latest rpm's fix the problem with -R0 not being recognized, they cause a new problem, namely that the -pp flag fails when sending to lpr (but works when sending output to a file). There is no indication of any error - the correct pages show up between square brackets, but no output is sent to lpr (this is with the -R0 flag). I would like to point out that it is totally illogical for dvips to have security turned on by default, since this means ordinary users will get error messages by doing what they have been doing on all previous versions of RedHat Linux, namely using dvips without the -R0 flag to print out their .dvi files. It would make much more sense for the default to be the behavior that has always been present, and let people who want security turned on do so with the appropriate flag.
Oops, the -pp option does work. It was my attempt to put the -R0 into /usr/share/texmf/dvips/config/config.ps that caused the problem. Ignore my last post, except for the fact that it is still totally illogical to have the default security setting for dvips make it impossible to print to a printer while having the default setting for config.ps be to try to send to a printer.
Okay, 'secure by default' reverted in 1.0.7-59.
*** Bug 77736 has been marked as a duplicate of this bug. ***
*** Bug 78536 has been marked as a duplicate of this bug. ***
*** Bug 81562 has been marked as a duplicate of this bug. ***