#1284 "cat" outputs duplicate CR - more info

Known_Feature
closed-invalid
nobody
MSYS (75)
2009-04-06
2009-04-06
Jan Echternach
No

See https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2728605&group_id=2435 for original report.

Additional info:

It seems highly unlikely to me that the bug is not in MSYS' cat.exe for the following reasons:

- Bug occurs with both cmd.exe and Cygwin's bash.exe.
- Filemon shows that MSYS-1.0.11's cat.exe is writing 1107 bytes which is already one byte too many.
- Bug does not occur with MSYS-1.0.10's cat.exe (Filemon shows that it's only writing 1106 bytes).
- Bug does not occur if MSYS-1.0.11's cat.exe processes a single 1106 byte input file containing both a.txt's and b.txt's contents such that the output sequence would be the same. The input data needs to be splitted into two files for the bug to occur.

Discussion

  • Jan Echternach
    Jan Echternach
    2009-04-06

    cat.exe Filemon logs

     
  • Earnie Boyd
    Earnie Boyd
    2009-04-06

    • milestone: --> Known_Feature
    • status: open --> closed-invalid
     
  • Earnie Boyd
    Earnie Boyd
    2009-04-06

    With your original report you gave file a.txt and file b.txt. I found that cat.exe b.txt > c.txt is enough to produce the result you see. The issue is that the redirect pipe open by cmd.exe to write the file is in text mode while the pipe open by cmd.exe is open in binary mode. If you unix2dos the two files a.txt and b.txt so that the <CR> aren't present to begin with then this ``duplicate'' isn't introduced. Furthermore cat.exe works appropriately in the shell it is expected to operate in (i.e.: MSYS' sh.exe). Therefore this is not a bug. If you wish to discuss this further then please follow up at mingw-users@lists.sourceforge.net.

    I did find a work around for you as follows:

    cat a.txt b.txt | tee c.txt >NUL