added character to lines in downloaded programs

[Mark Vollmers]

I've noticed something wierd that I was wondering if anyone else has experienced. recently, I have downloaded some programs off the web and tried to load them on our server (10.20). These are programs like netscape, and xv. When I try to run the scripts to install, I get errors. looking at the script, I see that every line has a ^M after it. This counts as one character, and I can go through line by line in VI and delete the character. When I go, the script runs fine. what is this? I download the programs using my NT station and unzip them there before moving the files to the server (we have a shared folder). Anyone seen this before, or how to avoid it? Thanks.

[Thierry Poels_1]

Hi,

I guess that you FTP'ed those files to your unix box in ascii mode instead of binary mode, or vice versa. Try in the other mode.

good luck,
Thierry.

[Rita C Workman · Accepted solution]

That's the and like you've noticed it shouldn't harm anything.
If you want to remove it, I believe you can run the utility dos2ux and it will clear it up.

You can get this when you download files from windows.

/rcw

[Mark Vollmers]

Actually, how we have it set up is that we have the DiskAccess software on the NT boxes. This allows me to assign /home to a drive letter (v:\). the folder that I am using is /home/adm/software/netscape (for example), so I download the program in windows to that directory, unzip it, and then hop over to the Unix box and run the scripts.

[Thierry Poels_1]

hmmmz, okay, missed that in my crystal ball ;)

then go for "dos2ux" as already mentioned.

Thierry.

[Bill Hassell]

It's important to note that sharing disks with incompatible operating systems is littered with problems. Unix and DOS/Windows filesystems are completely incompatible which is why you can't hook each other's disks to the opposite opsystem and try to read them. However, NFS, SMB and other filesystem sharing software makes the directory structures compatible, but not the files.

ASCII files in Unix have a single LF character at the end of every line and a null character at the end of the file.

However, in DOS/Windows, every ASCII file has a CR/LF pair at the end of every line. By convention, LF by itself is called a 'soft carriage return' and means something to WordPad and Word for Windows, but read that file in Notepad and it will look terrible.

So ASCII files are not portable without formal translation. That's why ftp has an ASCII mode--to perform the inter-system translation. Mainframe systems and commercial opsystems like MPE have many different (and incompatible) ASCII file stuctures.

As mentioned, dos2ux will fixup these DOS files and similarly, ux2dos goes the other way.

[Vincenzo Restuccia]

Edit the file in vi:

:%s/^M//g

^M in vi is ctrl+v and after invio.

[Mark Vollmers]

I tried the dos2ux command, and it worked last week. Now, I go and look at the file in vi and see the characters. Then, I type in the command (dos2ux makefile) and then look at the file again in vi and the characters are still there. what am I doing wrong?

Mark

[Joseph C. Denman]

try dos2ux ntfile > uxfile

You can keep from having to do this if you always ftp ascii file as ascii. By selecting ascii transfer via ftp, ftp will automatically convert the cr to newlines.

...jcd...

[Owen Campbell]

_