transferring binary from windows to hpux

[Shivkumar]

Dear Sirs,

When an ascii file is transferred to hpux; sometime i have seen ^M characters at the end of the line on hpux.

If binary file is transferred via ftp in bin mode from windows to hpux then do i need to take care of anything ?

Thanks,
Shiv

[Deoncia Grayson_1 · Accepted solution]

If your file is binary and you ftping to the Hpux in binary mode then you don't have to do anything on the hpux side as it will transfer as a binary file if you want to make sure you can type bin at the ftp prompt to make sure you are in binary mode.

[Shivkumar]

Actually, my question is ascii on windows and unix are different.

is binary also different ?

[Shivkumar]

Actually, my question is ascii on windows and unix are different.

is binary also different ?

If no; then how come binary files has been made platform independent ?

[James R. Ferguson]

Hi SHiv:

THe "^M" character you see is the graphic representation of a carriage-return character.

Unix uses a newline (linefeed) character to denote the end of a line. Windows uses a linefeed plus carriage return couplet to do the same.

When you specify an ASCII mode FTP transfer, the conversion to add or delete a carriage return character occurs automatically. Binary mode transfers are transparent transfers. Octets are transfered "as is" and nothing is added nor deleted.

If you find that you have a file in the wrong mode, you can use 'dos2ux' or 'ux2dos' to strip or add the carriage return character. See the man pages for 'dox2ux' for more information.

Regards!

...JRF...

[Arunvijai_4]

Hi Shiv,

DOS text files traditionally have carriage return and line feed pairs as their newline characters while Unix text files have the line feed as their newline character. So you get ^M when you transfer windows to Unix in ASCII mode.

-Arun

[Yogeeraj_1]

hi shiv,

The ASCII code is a standardized computer code which corresponds every letter, number, punctuation mark, etc. to a number between 0 and 255. This is the way computers store text files: each character in the file corresponds to a byte (8 bits, 2^8 = 256 possible combinations).

The line feed (LF) has ASCII code 10, and the carriage return (CR) has ASCII code 13. When computers first proliferated, there was some debate over how the end of lines should be stored in the file. To this day, UNIX systems use only the LF, while DOS systems use CRLF.

That is, if your file looks like this:

he
llo

UNIX would store this file as: 104 - 101 - 10 - 108 - 108 - 111
while Windows would store this file as: 104 - 101 - 13 - 10 - 108 - 108 - 111.


hope this helps too!

kind regards
yogeeraj

[Shameer.V.A]

Hi Shiv,

The problem is caused when a binary file ( eg: shar file) is downloaded to a pc. The pc
places
pc style end of lines in the file. The ^M is a visual representation of
the line feed not needed on unix. You can fix this by doing the
following:

# dos2ux sharfile > sharfile1
# sh sharfile1
x - README [compressed]
x - install.ksh [compressed]
x - inquiry256.1m [compressed]
x - inquiry256.ksh [compressed]
x - inquiry256 [compressed]

Hope these informations will help you..

Regards,

Shameer

[Arunvijai_4]

Hi Shiv,

You asked about "If binary file is transferred via ftp in bin mode from windows to hpux then do i need to take care of anything ?"

No, "bin" mode is fine for binary files. You dont need to take care of anything except checksum value.

-Arun

[Muthukumar_5]

Problem is becuase of file format encoding. If you are getting ^M characters then file is in DOS format. To convert that use as,

# dos2ux

Use binary mode with ftp when transfer files between two different platforms.

--
Muthu