Bug 71650 - dvips fails to write to lpr
Summary: dvips fails to write to lpr
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tetex
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
: 75041 75731 77736 78536 81562 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-16 02:49 UTC by Jay Berkenbilt
Modified: 2007-04-18 16:45 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-11-08 21:44:23 UTC
Embargoed:


Attachments (Terms of Use)
Patch to make '-R0' option work (389 bytes, patch)
2002-08-16 16:49 UTC, Tim Waugh
no flags Details | Diff

Description Jay Berkenbilt 2002-08-16 02:49:50 UTC
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.

Comment 1 Tim Waugh 2002-08-16 14:52:08 UTC
This is probably related to it running securely by default now.

Comment 2 Tim Waugh 2002-08-16 16:49:48 UTC
Created attachment 71185 [details]
Patch to make '-R0' option work

Comment 3 Tim Waugh 2002-08-16 16:51:00 UTC
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.

Comment 4 Tim Waugh 2002-08-16 17:00:21 UTC
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.

Comment 5 Jay Berkenbilt 2002-09-12 16:47:44 UTC
Since this still exists on null and the topic came up on the list, I've updated
the product version from limbo to null.

Comment 6 Tim Waugh 2002-10-04 09:57:28 UTC
Updated version to 8.0 since it didn't get fixed for release.

Comment 7 Tim Waugh 2002-10-04 09:57:46 UTC
*** Bug 75041 has been marked as a duplicate of this bug. ***

Comment 8 Mate Wierdl 2002-10-04 14:25:48 UTC
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


Comment 9 Tim Waugh 2002-10-11 16:48:47 UTC
*** Bug 75731 has been marked as a duplicate of this bug. ***

Comment 10 Alan Crosswell 2002-10-12 23:13:56 UTC
-R0 not working of course also breaks any execution of \specials.
Resulting in "Failure to execute %s; continuing" error message.


Comment 11 Mate Wierdl 2002-10-14 00:55:43 UTC
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]

Comment 12 bill 2002-10-23 22:42:55 UTC
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

Comment 13 Tim Waugh 2002-10-24 09:03:11 UTC
Yes--read all the above comments, you'll see that we know that -R0 is broken,
and there is a patch to try.

Comment 14 Ed Friedman 2002-11-06 18:49:13 UTC
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.



Comment 15 Ed Friedman 2002-11-08 21:44:16 UTC
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.

Comment 16 Tim Waugh 2002-11-11 17:47:36 UTC
Okay, 'secure by default' reverted in 1.0.7-59.

Comment 17 Tim Waugh 2002-11-12 22:16:16 UTC
*** Bug 77736 has been marked as a duplicate of this bug. ***

Comment 18 Tim Waugh 2002-11-25 10:10:16 UTC
*** Bug 78536 has been marked as a duplicate of this bug. ***

Comment 19 Tim Waugh 2003-01-10 15:25:57 UTC
*** Bug 81562 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.