duster@dasys1.UUCP (Harry Milkman) (01/26/89)
After transferring a file from an MS-DOS PC to a 3B2 running UNIX, using kermit, the <cr> character (hex 0D) is stripped from my file. Does anyone have any idea why this happens?
prophet@nitro.ATT.COM (Mike Brooks) (01/26/89)
In article <8458@dasys1.UUCP> duster@dasys1.UUCP (Harry Milkman) writes: >After transferring a file from an MS-DOS PC to a 3B2 running UNIX, using >kermit, the <cr> character (hex 0D) is stripped from my file. > >Does anyone have any idea why this happens? Probably because there is a mapping option set in the protocol. System V (and other UNIX (r) based operating systems) use line feed as end of line; MS-DOS uses the carriage return - linefeed combination. Michael Brooks attunix!nitro!prophet
terry@eecea.eece.ksu.edu (Terry Hull) (01/27/89)
In article <8458@dasys1.UUCP> duster@dasys1.UUCP (Harry Milkman) writes: >After transferring a file from an MS-DOS PC to a 3B2 running UNIX, using >kermit, the <cr> character (hex 0D) is stripped from my file. > >Does anyone have any idea why this happens? Yes, you are transferring the file in text mode. Ckermit on the 3B2 assumes that you want to make the text file UNIX compatible, so it strips the <cr>. If you want to keep the <cr>s, use binary mode. Then ckermit will leave the file contents alone and will not try to "fix" it. -- Terry Hull Department of Electrical and Computer Engineering Kansas State University INTERNET: terry@eecea.eece.ksu.edu Manhattan, KS 66502 UUCP: rutgers!ksuvax1!eecea!terry
billp@scr1.UUCP (01/28/89)
In article <8458@dasys1.UUCP>, duster@dasys1.UUCP writes: > After transferring a file from an MS-DOS PC to a 3B2 running UNIX, using > kermit, the <cr> character (hex 0D) is stripped from my file. > > Does anyone have any idea why this happens? Kermit transforms textfiles into the correct text format for the receiving system if it is told the file is a textfile. If you want to move a non-text file between a Unix box and an MS-DOS machine you must tell the Unix side the file is BINARY. Otherwise Kermit will change the Unix newline (linefeed) to carriage return/linefeed going to DOS and strip the CR going to Unix. Unix sees dos' cr/lf pair as a ^M followed by newline which is incorrect for Unix. Kermit will also translate on other os's including Unix, OS/32 and ascii<--> ebcdic on IBM. Hope this helps explain why this happens. -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Play/ .. rutgers!pedsga!tsdiag!scr1!billp "Why do they call it software when the manual's so hard to understand?"