Bug #19766 for String-Escape: Printable function does not handle a CRLF newline

Wed Jun 07 11:58:10 2006 Guest - Ticket created

Subject:

Printable function does not handle a CRLF newline

If String::Escape::Printable is given a newline character of \x0d\x0a, it will return "\n" along with the control value of \x0a. Without digging into it much deeper, I don't know what type of effect a small fix might have on the rest of the module.

Mon Feb 01 18:46:38 2010 EVO [...] cpan.org - Correspondence added

On Wed Jun 07 11:58:10 2006, guest wrote: Show quoted text

> If String::Escape::Printable is given a newline character of \x0d\x0a, > it will return "\n" along with the control value of \x0a. > > Without digging into it much deeper, I don't know what type of effect a > small fix might have on the rest of the module.

Hello, and thank you for the feedback on String::Escape. Do you happen to recall the context this issue came up in? It appears that the behavior you're describing reflects use of Perl on a platform where "\n" produces the character \x0a, which might occur on non-Unix platforms. In that case, I think this might be considered a feature, but either way it certainly deserves some documentation... -Simon

Mon Feb 01 18:46:41 2010 The RT System itself - Status changed from 'new' to 'open'

Mon Feb 01 18:46:46 2010 EVO [...] cpan.org - Correspondence added

On Wed Jun 07 11:58:10 2006, guest wrote: Show quoted text

> If String::Escape::Printable is given a newline character of \x0d\x0a, > it will return "\n" along with the control value of \x0a. > > Without digging into it much deeper, I don't know what type of effect a > small fix might have on the rest of the module.

Hello, and thank you for the feedback on String::Escape. Do you happen to recall the context this issue came up in? It appears that the behavior you're describing reflects use of Perl on a platform where "\n" produces the character \x0a, which might occur on non-Unix platforms. In that case, I think this might be considered a feature, but either way it certainly deserves some documentation... -Simon

Mon Feb 01 18:57:22 2010 cebratcher [...] gmail.com - Correspondence added

From:

cebratcher [...] gmail.com

On Mon Feb 01 18:46:46 2010, EVO wrote: Show quoted text

> On Wed Jun 07 11:58:10 2006, guest wrote:

> > If String::Escape::Printable is given a newline character of

> \x0d\x0a,

> > it will return "\n" along with the control value of \x0a. > > > > Without digging into it much deeper, I don't know what type of

> effect a

> > small fix might have on the rest of the module.

> > Hello, and thank you for the feedback on String::Escape. > > Do you happen to recall the context this issue came up in? > > It appears that the behavior you're describing reflects use of Perl on > a platform where "\n" > produces the character \x0a, which might occur on non-Unix platforms. > > In that case, I think this might be considered a feature, but either > way it certainly deserves > some documentation... > > -Simon

If my memory serves me right, the platform was win32. Now that I'm thinking about it, unless it was platform-specific, there'd be no guarantee the inverse would apply cleanly. Unfortunately I don't recall the full context of this bug.. Sorry about that. -Clif

Mon Feb 01 19:08:30 2010 simonm [...] cavalletto.org - Correspondence added

Subject:	Re: [rt.cpan.org #19766] Printable function does not handle a CRLF newline
Date:	Mon, 1 Feb 2010 19:07:27 -0500
To:	bug-String-Escape [...] rt.cpan.org
From:	Matthew Simon Ryan Cavalletto <simonm [...] cavalletto.org>

On Feb 1, 2010, at 6:57 PM, cebratcher@gmail.com via RT wrote: Show quoted text

> On Mon Feb 01 18:46:46 2010, EVO wrote:

>> On Wed Jun 07 11:58:10 2006, guest wrote:

>>> If String::Escape::Printable is given a newline character of \x0d\x0a,it will return "\n" along with the control value of \x0a.

>> >> It appears that the behavior you're describing reflects use of Perl on a platform where "\n" produces the character \x0a, which might occur on non-Unix platforms. >> >> In that case, I think this might be considered a feature, but either way it certainly deserves some documentation...

> > If my memory serves me right, the platform was win32. Now that I'm thinking about it, unless it was platform-specific, there'd be no guarantee the inverse would apply cleanly.

The way this is set up, \r and \n are always mapped to their local equivalents. Escaping any string and then un-backslashing it should always work assuming you don't switch platforms, but if you're transferring data between Unix and Windows environments, things could go haywire. I think that'z acceptable -- this isn't intended to be a file-transfer or network protocol utility -- but I'll try to remember to add some notes on this subject in the documentation for the next release. -Simon