in reply to Re: Compare and group unmatched records from 2 CSV files together
in thread Compare and group unmatched records from 2 CSV files together


Thanks AppleFritter! I tried using the sample code but I am getting the error "CSV parse error: EIF - CR char inside unquoted, not part of EOL..."

I tried looking up the error and found that this could be a data problem. I have recreated the same sample I gave and made sure that there are no extra characters/spaces but still getting the same result. Any idea why I am getting this?
  • Comment on Re^2: Compare and group unmatched records from 2 CSV files together

Replies are listed 'Best First'.
Re^3: Compare and group unmatched records from 2 CSV files together
by Tux (Canon) on Jun 24, 2014 at 11:39 UTC

    This smells like a binary \r is inside an unquoted field and the binary option is not passed to the parser. What versions of Text::CSV (and if installed Text::CSV_XS) and Tie::Array::CSV are you using?

    It might help to also show us a hextdump of the data that fails.


    Enjoy, Have FUN! H.Merijn
Re^3: Compare and group unmatched records from 2 CSV files together
by Laurent_R (Canon) on Jun 24, 2014 at 22:01 UTC
    Or this smells like a file prepared under Windows and used under Linux or Unix. If this is the case, just remove the CR (carriage returns, or \r) characters from your file before processing. One possible command to strip a file from these noisy Windows files under your shell:
    perl -pi.bak -e 's/\r//g;' my_file.txt
    This removes the Windows CR characters from the file and saves the original fila as my_file.txt.bak (just in case something goes wrong).
        Right, usually available on Linux, but not on all Unix environments (for example not on our version of AIX, where I made a dos2unix alias which uses the above Perl one-liner).

      And it will remove \r also when correctly quoted:

      code,value 1,"abc\rdef"

      Is valid CSV (binary => 1 needed for Text::CSV and Text::CSV_XS), but will change content with that change. Not good!


      Enjoy, Have FUN! H.Merijn
        Not quite sure to understand what the point is. I just know that I used to have a regex like this:
        s/\r\n/\n/
        or even:
        s/\r\n$/\n/
        but it turned our to insufficient, because the input data sometimes had line ending with "\r\r\n" and sometimes also "\r" in the middle of the line, generating all kinds of probblem. In the end, this regex:
        s/\r//g
        turned out to solve all the problems. Now, of course, it depends on what your input data is and what you need at the end of the day. With different data and different goals, the regex would probably have to be changed. But that's not hot news, if you need to do data munging, the first prerequisite is to know your data well.