> I think paste can not handle the MS carridge returns... Take a look > at the last four lines.(I tried the same files on solaris and got the same > problem, but when I tried recreating them using solaris's echo the problems > went away!)
Thank you for your report. However, the problem is not in paste. The carriage returns are being printed and are being processed by your terminal. > E:\backup\tmp\old>echo 1 > out2 > E:\backup\tmp\old>echo 2 >> out2 > E:\backup\tmp\old>echo 3 >> out2 > E:\backup\tmp\old>echo applenuts > out1 > E:\backup\tmp\old>echo bakedgoods >> out1 > E:\backup\tmp\old>echo cannedfruits >> out1 [...] > E:\backup\tmp\old>paste out1 out2 > applenut1 > bakedgoo2 > cannedfr3 ts I was able to recreate the return, newline sequence using the standard shell printf program which allows explicit control over newlines more easily than using echo. (I usually use echo myself unless I need that extra level of control.) printf "applenuts\r\n" > out1 printf "bakedgoods\r\n" >> out1 printf "cannedfruits\r\n" >> out1 printf "1\r\n" > out2 printf "2\r\n" >> out2 printf "3\r\n" >> out2 paste out1 out2 applenut1 bakedgoo2s cannedfr3its So it *appears* that I can recreate your problem. However, those return characters are being handled by paste. Let's print all characters and make invisible characters visible. If 'cat -v' is not available to you then you will need to use 'od -c' instead and deal with the differences in output. paste out1 out2 | cat -v applenuts^M 1^M bakedgoods^M 2^M cannedfruits^M 3^M Now it should be apparent what is happening. Paste is adding a tab character between the fields as it should. But the return character which is part of the input files are telling the terminal to move to the start of the line. The tab moves right from there. The result is that it overwrites part of the line. This is working as it should work because as the old adage says, it is doing exactly what you told it to do and not want you wanted it to do. You reported that using the Solaris echo worked. On unix systems the end of line convention is a single newline and not a return-newline pair such as it is on MS systems. Therefore the file did not contain any return characters on the Solaris system. Since the numbers are very small the tab skips over them and it appears to work because you can't tell the difference. If the out2 file containing the numbers instead contained wider fields it would be apparent in that case too. It is not clear to me if you have a problem with the MS-Windows version of the tools. Handling the end-of-line sequence as two characters has always been troublesome. I can't deduce if you have a broken version there or are just copying files from MS to UNIX and therefore mixing end-of-line conventions. If you can do everything on one host and it works then I think all of the tools are working fine. If it fails to work on MS-Windows when run completely on that host then I suspect that you have a broken version of the tools there. You should update to the current versions and try again. However, because MS-Windows has different conventions for binary and text files such as this extra return character it makes it very difficult and sometimes impossible to operate correctly on MS-Windows. http://cygwin.com/ Cygwin Home Page http://cygwin.com/faq/ Cygwin FAQ. http://cygwin.com/bugs.html Cygwin Bug Report Guidelines. This is a good reference for general bug reporting. Hope that helps. Bob _______________________________________________ Bug-textutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-textutils
