from UNIX to DOS, still can't make it work, end-of-line

[Vittorio_3]

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xd2fb5913c445774a801c11ac7386b98f,00.html

This a follow up for the post above, I still can???t get it worked with original file, the test file being created with VI works fine, so I think that my file is carrying something special chars, this file made multiple hops before being FTP (get) to UNIX, and originally was created on Stratus.
But fact is that I can see this file clearly on UNIX (end-of-line is OK) but can???t do in Windows after FTP or email it as a attachment after FTP with bin, ascii, and using ux2dos. Lines are broken, and I think more important some lines are multiplied !!!!! (see sample on link).
That what I tried (all combinations, run from script):
ftp (bin/ascii/..) get ???file???
ux2dos file > filed
ftp (bin/ascii/???) put file/filed or email as attachment [include plain/text filed]???.

I???m thinking to reformat my file explicitly deleting special chars, taking first 45 bytes (its length) and putting end-of-line for windows < \r\n > at the end. I think it can be done with awk/sed ? Also how I can see contents of my file in UNIX in bin ? Is there any special mode for VI ?

Thanks
Nikola

[Brian Bergstrand]

Are you absolutley sure that the file is ASCII? There was another poster recently who was having similar troubles. Turned out that the file was orginally created on MVS using the EBCDIC (sp?) character set. So he had to convert the file to ASCII and then use FTP or ux2dos to convert the line endings.

Could something similar be occuring with your file?

[Steven E. Protter]

If the file's not too big, lets see it.

You can use printf or awk to print the contents of the file in hex. You'll probably see something interesting in there.

SEP

[doug mielke]

Can also try od and xd to see the contents as a troubleshooting step.

[Ken Hubnik_2 · Accepted solution]

When you are doing the ftp is binary mode turned on or off??

[A. Clay Stephenson]

So that we can see exit what is in the file, do this on your UNIX box:

od -Ad -ta myfile

and on your Windows box:
debug myfile
enter 'd' a few times and then 'q'.

This will display any control characters in printable form and if you post those results, someone should be able to craft a filter for you.

[Massimo Bianchi]

Hi,
you said you created this file with stratus.

I do not know what is it, but are you sure that it is written in ascii ?

Have you the chance to save the file in another format, and then take the file to the window server ?

There are a lot of good hex editor for unix, free download at:

http://hpux.connect.org.uk/hppd/hpux/Development/Tools/hexedit-0.9.7/

or ultraedit32 for the window server.

Massimo

[Vittorio_3]

Thanks, all

I attached output for hex display and it's all nice, and this time it also worked fine if I do:
FTP __ GET FILE (no bin/ascii)
UX2DOS FILE > FILED
FTP __ FILED

so I will start all over, checking every setting. Will keep all posted. Thanks to all.

[Volker Borowski]

Hi,
could you be more specific about what use ?

UNIX / WINDOWS / gzip / WINZIP

...could be anything. I searched google for "winzip gzip incompatible" and you get some stuff there. I.e. if cygwin-zip is involved this might be a problem. If winzip is no quite current in its version, it might not be able to handle a plain .gz file but will require a tared-gzip (even if there is only one file in it. So you could try

tar cvf ARCHIVE.TAR ./file_to_be_winunziped
gzip ARCHIVE.TAR

ftp this one (binary)

and open ARCHIVE.TAR.gz with winzip.

Good hunting
Volker

[Vittorio_3]

Thanks, Volker
Thanks all.

I ended with that gzip/winzip don't like each other at least on my machine, as flat file working fine being FTP from UNIX to WIN.
I assumed that winzip will work fine for .gz or .tgz.

Will keep shooting.
NIkola

It'a another real sample of my data attached.

[Mark Greene_1]

To guarantee that you only have ASCII data, try this:

strings old_file > new_file

and then compare the sizes of the two files to see how much (if any) data you lost.

mark

[Vittorio_3]

Thanks, Mark

checked with srtrings. Sizes are all same.
It's defenetely gzip vs winzip problem.
I'm working with systems to get new zipper.

Thanks to all
Nikola

[Fred Martin_1]

Search for a thread with my name in it, I had a similar situation.

Text file created in unix had a ^L for top-of-form, but when ftp'd to an NT box, it lost the TOF.

Didn't matter if I sent it over as ascii or binary, etc.

Turns out that it's the fault of the notepad/wordpad program being used and varies between Win95,98,ME and NT.