in reply to Re: Parsing a 3-Column Tab-Deliminated File
in thread Parsing a 3-Column Tab-Deliminated File

my $dbh = DBI->connect("DBI:CSV:f_dir=.;csv_sep_char=\t") or die "Cannot connect: " . $DBI::errstr;

I had a hard time trying the DBD::CSV example, until I saw in the documentation that the default value for csv_eol was \015\012 (I'm on Unix, so \n has other value here). When I stuck a csv_eol=\n to that line everything started to work.

Later I thought it would also be safe for Windows or Mac users to specify the csv_eol explicitly, since \n would map to the correct sequence of characters for the architecture. However, I haven't seen anyone recommending this ("Use always csv_eol=\n, unless working with files from other platforms"), maybe because there's a good reason for not doing so. Is there any?

Update: Fixed typo spotted by planetscape.

--
David Serrano

Replies are listed 'Best First'.
Re^3: Parsing a 3-Column Tab-Deliminated File
by jZed (Prior) on Oct 03, 2006 at 15:50 UTC
    Thereby hangs a tale. I inherited DBD::CSV from Jochen Weidman back in 1999 and at that time it already had many users. Jochen had decided on using windows-style eol as the default because the primary intended audience was users of Excel. I left the default as-is in DBD::CSV for backward compatibility but in my DBD::AnyData I changed the default to be "\n" (i.e. the line ending on the platform where the script is being run) which usually works better except when people get files from elsewhere. So, in short, no, always using "\n" is not a bad idea.
[reply]

In Section Seekers of Perl Wisdom