Skip Menu |

This queue is for tickets about the Text-CSV_XS CPAN distribution.

Report information
The Basics
Id: 120145
Status: rejected
Priority: 0/
Queue: Text-CSV_XS
People
Owner: Nobody in particular
Requestors: MHC [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Wed Feb 08 11:51:03 2017 MHC [...] cpan.org - Ticket created
Subject: Is setting eol to \r\n really a safe choice?
The docs for the eol option say: When not passed in a generating instance, records are not terminated at all, so it is probably wise to pass something you expect. A safe choice for eol on output is either $/ or \r\n. Common values for eol are "\012" (\n or Line Feed), "\015\012" (\r\n or Carriage Return, Line Feed), and "\015" (\r or Carriage Return). The eol attribute cannot exceed 7 (ASCII) characters. *** \r\n probably isn't a safe choice for most users, since if they're on a platform that uses \r\n line endings, perl already does automatic CRLF translation. I'm not sure if the second paragraph should be changed, since some people may want to generate files with Windows line endings on *nix. But I wouldn't say that's common.
  Sat Feb 11 12:08:09 2017 HMBRAND [...] cpan.org - Status changed from 'new' to 'rejected'
  Sat Feb 11 12:08:37 2017 h.m.brand [...] xs4all.nl - Correspondence added
Subject: Re: [rt.cpan.org #120145] Is setting eol to \r\n really a safe choice?
Date: Sat, 11 Feb 2017 18:06:55 +0100
To: bug-Text-CSV_XS [...] rt.cpan.org
From: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
On Wed, 8 Feb 2017 11:51:09 -0500, "Max Carey via RT" <bug-Text-CSV_XS@rt.cpan.org> wrote: Show quoted text
> \r\n probably isn't a safe choice for most users, since if they're on > a platform that uses \r\n line endings, perl already does automatic > CRLF translation.
This is about the CSV *DATA*, not about the program or script that reads it. Having \r\n in CSV *data* is *always* safe! Show quoted text
> I'm not sure if the second paragraph should be changed, since some > people may want to generate files with Windows line endings on *nix. > But I wouldn't say that's common.
Using \r\n make the data most portable and readable on both unix/linux *and* windows. The parser should be able to deal with both, but people that want to inspect the data with a text editor (vi, notepad) now *both* will see each record on a new line. IETF agrees on this. In fact, it is my bible. https://tools.ietf.org/html/rfc4180#section-2 : 1. Each record is located on a separate line, delimited by a line break (CRLF). For example: aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF I'll close this ticked as rejected, hoping I informed you enough. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.25 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Download (untitled)
application/pgp-signature 473b

Message body not shown because it is not plain text.