Skip Menu |

This queue is for tickets about the Filter CPAN distribution.

Report information
The Basics
Id: 53964
Status: resolved
Priority: 0/
Queue: Filter

Owner: RURBAN [...]
Requestors: user42 [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Subject: Filter::decrypt vs crlf
Date: Mon, 25 Jan 2010 11:32:39 +1100
To: bug-Filter [...]
From: Kevin Ryde <user42 [...]>
Download (untitled) / with headers
text/plain 768b
I wondered what if anything a filter operating on binary input might have to do to ensure there's no crlf translation on msdos. I gave Filter::decrypt a try on the below with a faked-up PERLIO=crlf, perl encrypt PERLIO=crlf perl => Can't find string terminator '"' anywhere before EOF at line 2. The standalone decrypt doesn't get back to the original either, PERLIO=crlf perl decr The "aZ" in is cooked up to come out as CR LF in the encrypted file :-). Dunno if PERLIO=crlf forces more crlfs than actually happens on msdos, and I suppose Filter::decrypt is mainly an example, but it'd be good to show where a binmode() or whatever should be inserted for a binary type filter to see correct bytes.
text/x-perl 14b
print "aZ\n";
Download (untitled) / with headers
text/plain 200b
Fixed with newer perls (at least) alias pb="perl -Mblib" PERLIO=crlf pb decrypt/encrypt mytest # no crlf in binary output PERLIO=crlf pb decrypt/decr mytest.pd # crlf in text output -- Reini Urban

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to