Bad ASCI Text files 
Author Message
 Bad ASCI Text files

HELP...................

Does anybody know why an ASCI text file created in Windows Notepad causes
problems when FTPed over to UNIX?

A file that is created in Notepad, then FTPed over to unix looks exactly the
same as a file created in unix.  In other words, you can open both files
with vi text editor from unix and they look the same.  It seems that as far
as unix is concerned they are the same, since vi works on both.

The problem arises when you try to perform any file manipulation on the file
using a perl script.  Perl doesn't seem to be recognizing the Notepad file
as a valid text file.  Or at least thats what I think is going on.

Does anybody have any ideas?  Anyone run into this before?  I can't be the
only one.  Big gold star for whoever figures it out.

Thanks everyone!!



Sat, 30 Sep 2000 03:00:00 GMT  
 Bad ASCI Text files


Quote:
> Newsgroups: comp.lang.perl.modules

Is this really a question about modules? Maybe you meant to post to
c.l.p.misc.

Quote:
> Does anybody know why an ASCI text file created in Windows Notepad
> causes problems when FTPed over to UNIX?

Maybe you put the wrong data in the file. Maybe you didn't upload in text
mode. Maybe the file is too large. Maybe the file is in the wrong format.
Maybe there's a bug in Windows, Windows Notepad, the FTP client, the FTP
daemon, or the Unix system. There are lots of possible reasons!

Quote:
> A file that is created in Notepad, then FTPed over to unix looks exactly
> the same as a file created in unix.  In other words, you can open both
> files with vi text editor from unix and they look the same.  It seems
> that as far as unix is concerned they are the same, since vi works on
> both.

I don't think that that follows. If you want to see what's really in a
file, use a utility like od, not vi. (I always pipe something like this:
'od -xc somefile | more'.)

Quote:
> The problem arises when you try to perform any file manipulation on the
> file using a perl script.  Perl doesn't seem to be recognizing the
> Notepad file as a valid text file.  Or at least thats what I think is
> going on.

Do you have a recent version of Perl? Does perldiag have anything uselful
to say about Perl's diagnostic message? If not, could you tell us Perl's
message? That would be a big help.

Good luck with it!

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Sat, 30 Sep 2000 03:00:00 GMT  
 Bad ASCI Text files

Quote:

> HELP...................

> Does anybody know why an ASCI text file created in Windows Notepad causes
> problems when FTPed over to UNIX?

> A file that is created in Notepad, then FTPed over to unix looks exactly the
> same as a file created in unix.  In other words, you can open both files
> with vi text editor from unix and they look the same.  It seems that as far
> as unix is concerned they are the same, since vi works on both.

> The problem arises when you try to perform any file manipulation on the file
> using a perl script.  Perl doesn't seem to be recognizing the Notepad file
> as a valid text file.  Or at least thats what I think is going on.

> Does anybody have any ideas?  Anyone run into this before?  I can't be the
> only one.  Big gold star for whoever figures it out.

> Thanks everyone!!

My suspicion is that you are probably running into problems with ^M at
the end of each line.  If this text file you are trying to perform file
operations on is the script itself (ie, you try to run this file as the
script), you will get a message like "Command not found" from the
shell.  Then, when you try to vi the file, it will look just fine, and
drive you crazy.

In this case, you are probably on a Linux box, and you are actually
using vim, a vi clone.  vim tries to be smart, and if it sees a ^M at
the end of a line, it will silently hide it from you, because it thinks
"well, they probably don't want to be bothered with seeing this".  The
only way to get around this is to put a .exrc in your home directory
with the line:
:set binary
in it (in addition to any of the other options you want).

Now, if you are simply using this text file for data, it's probably
something similar, with respect to ^Ms at the end of each line.

Of course, you can always just set your FTP transfer mode to "ASCII"
instead of "Binary".

Brian Mathis

  vcard.vcf
< 1K Download


Sat, 30 Sep 2000 03:00:00 GMT  
 Bad ASCI Text files

Quote:
> Does anybody know why an ASCI text file created in Windows Notepad causes
> problems when FTPed over to UNIX?

vi does not show control characters.  While in vi try this :set list
(unset with :set nolist).  This should show you the Control-M's at the
"end" of each line.  DOS uses carriage-return & line-feed to indicate
end-of-line.  Unix uses just line-feed.

Globalally changing all of the Control-M's to nothing should fix the
problem.

Some FTP programs are smart enough to figure out that you are going from
DOS to Unix, some are not.  Some allow you to select the OS on the other
end.  Those that have either of these capabilities take care of this
Control-M problem for you.

--

Stephen Hinchey
Director
Barbary Coast Consulting, Inc.

voice 510-653-7090
fax   510-653-7096



Sat, 30 Sep 2000 03:00:00 GMT  
 Bad ASCI Text files

Quote:

> Some FTP programs are smart enough to figure out that you are going from
> DOS to Unix, some are not.

Bizarre.  FTP usually has (at least) two "types" of transfer: binary
(officially called image)  and text (officially called "ascii", though
this is a misnomer, since ASCII is a 7-bit code).

If you want to transfer text files, then use a "text" type of transfer.

There is no need to "figure out" the OS at each end: the client and
server just need to know how to transfer text when asked to, and how
text files are stored in _their_ OS.  No need for either participant to
know anything about the internal workings of the _other_ end.

RFC959 says:

      For the purpose of standardized transfer, the sending host will
      translate its internal end of line or end of record denotation
      into the representation prescribed by the transfer mode and file
      structure, and the receiving host will perform the inverse
      translation to its internal denotation.

Quote:
> Some allow you to select the OS on the other end.

You must have met some bizarre FTP?  Even IBM mainframes didn't expect
to do that, they merely followed the same procedures as anyone else for
transferrring text mode data.

It would be ludicrous for every implementation of FTP to have to
understand every other possible OS that might be out there.  It's true
that some systems recognize when they have another system of the _same_
type at the other end, and then take advantage of certain optimisations
or offer a richer set of functions.

Quote:
> Those that have either of these capabilities take care of this
> Control-M problem for you.

Certainly; and character code discrepancies too, if they're any good
(e.g Fetch on the Mac).   But this isn't because they know anything
about the OS at the other end.

I don't know where to set f'ups to, but as sure as heck it isn't this
group.  Shucks, I'm setting to poster - override it if you think you
know of a proper forum.



Sat, 30 Sep 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. How to substract a uniq integer from a ASCI string

2. Text filter for bad words (Continuation)

3. bad text index?

4. Problem with converting DOS text files to UNIX text files

5. File::Copy WIn32 bad file descriptor

6. remove text from text file

7. How to replace text in a text file.

8. How to retrive information from text-plain file by using ODBC text driver

9. changing text in a text file

10. Inserting text in text file

11. Grabbing text from a web site and storing in a text file

12. Search and Replace text in text files???

 

 
Powered by phpBB® Forum Software