In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jeff Zucker) wrote:
> "Scott R. Godin" wrote:
> >
> > unable to set ;csv_eol=\015, but saving the file via bbedit to DOS
> > instead of Macintosh, the code works?!? what the hell?
>
> AFAIK,
>
> 1. If you are on a MAC and have all MAC-formatted files, don't set
> csv_eol at all, DBD::CSV should do the right thing.
unfortunately this is not the case, as in CSV.pm there is the following
line:
$opts{'eol'} = $meta->{'eol'} || $dbh->{'csv_eol'} || "\015\012";
so, for a Mac file I need to set it explicitly.
> 2. If you are on a MAC and have all DOS formatted files, set csv_eol to
> \015\012.
Since this is the default (see above) it isn't necessary. As long as the
file has DOS linefeeds, setting to \015\012 or not setting this at all
results in usable data access.
> 3. If you are on a MAC and have mixed files
>
> a. convert them all to one format before processing (recommended)
>
> or
>
> b. for the files that you know are DOS formatted, set csv_eol to
> \015\012 and
> do not set it all for the MAC formatted files
>
> > All well and good, except that the file is generated by a whole suite of
> > perl scripts
>
> So use the scripts to put a MAC eol in the file and forget about csv_eol
> in the report generating scripts.
Well the issue here is one of independance between Mac and Unix -- if
the file is generated on the Mac, I should be able to set csv_eol to
\015 and have DBI 'do the right thing', likewise with unix setting
csv_eol to \012
now, if DBI is creating the table, all is well and good -- the present
setup creates files with \015\012 and as long as you DO NOT set csv_eol,
everything is fine. It's when you are creating the "database files" with
other applications and expect it (DBI and DBD::CSV) to do what it says
it's supposed to, that things go flooey.
--
Scott R. Godin | e-mail : [EMAIL PROTECTED]
Laughing Dragon Services | web : http://www.webdragon.net/
