Description: ------------ We're using File_CSV to parse and store imported CSV data. This works fine except for when the CSV file only contains one column, such as === a@b.com c@d.net e@f.org === When using File_CSV::discoverFormat(), the following warning is issued: === Warning: Could not discover the separator in /var/www/html/PEAR/PEAR.php on line 762 === The reason for this is obviously that the file doesn't contain any separator character, however the file is still a completely valid CSV file (AFAIK). Thanks! Reproduce code: --------------- Save === a@b.com c@d.net e@f.org === to a file, say /tmp/onecol.csv and run the following code: === $aConfig = File_CSV::discoverFormat("/tmp/onecol.csv"); === Expected result: ---------------- $aConfig to be Array ( [fields] => 1, [sep] => NULL, [quote] => NULL ) Or some other format that aids the next method used (typically: File_CSV::read()) Actual result: -------------- Pear warning: Warning: Could not discover the separator in /var/www/html/PEAR/PEAR.php on line 762

Hi, I've 'fixed' the problem by commenting the if-statement that generates the error message. This seems to work fine on our system, but I'm sure that someone can fix a much more elegant solution to this problem. I'm pasting the diff here; it might help someone resolve the problem temporarily, and hopefully a developer might be able to use it as a starting-point for a better solution. Cheers, /JS Patch for CSV.php === 385,388c385,387 < // This if-statement generates error when reading a one-column CSV file < // if (empty($fields)) { < // return File_CSV::raiseError('Could not discover the separator'); < // } --- > if (empty($fields)) { > return File_CSV::raiseError('Could not discover the separator'); > } ===

The problem here is that the class doesn't make a difference between if users are passing some funny seperators like $ or so, or none at all or even it's some error happening that messes the sep finding, so I'm not sure in what foot I should step at the moment in regards to this, but setting the config manually works just fine, you can read and write fine then, at least worked for me it seems. And also, at the moment at least I can't do anything that would break BC, but I was thinking about a solution, that if no sep is found, each line is just taken as one "message" foo$bar foo2$bar2 If $ was a sep for some person, and the class won't find that of course (it has those seps hard coded atm at least) then the class would not give a error but handle this "foo$bar" not "foo" and "bar" if $ was a valid sep, but that would break BC :(

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. Fixes Bug #2827, allows 1 field per line in discoverFormat as well as the config overall, with no separator (which is the standard), removed one error check to fix this issue as well as moving error checking around in _conf, might give some people issues (can't see how tho), also added a new param to discoverFormat so one can inject a check for $ as a separator or something like that.