[Info-vax] wrong file format

[Bill Gunshannon]

On 12/30/20 1:34 AM, Phillip Helbig (undress to reply) wrote:
> In article <rsg97u$1m8$1 at dont-email.me>, Dirk Munk <munk at home.nl>
> writes:
> 
>>>>>>> In the end, I managed to transfer it again (don't ask!) and somehow,
>>>>>>> magically, it was OK.
>>>>>>>
>>>>>> I've dealt with problems like these before, usually caused by
>>>>>> applications that were not written for VMS.
>>>>>>
>>>>>> You need to have a bit of a feeling for the different file types of VMS
>>>>>> to fix these problems, but if you have that, it's very simple to solve
>>>>>> these little puzzles.
>>>>>
>>>>> I don't know how many times I've used SET FILE/ATTR or CONVERT or TECO
>>>>> to fix things like this.  I can usually look at the contents, look at
>>>>> DIR/FULL, and see what needs to be done if they don't match, but this
>>>>> was somehow different.
>>>>
>>>> Nice that it was fixed! And no, I do not belive in magic... :-)
>>>
>>> And, just so people don't think, based on earlier comments, that
>>> Unix is somehow immune, I frequently have to remove "^M" characters
>>> from text files on Unix. Unix's only saving grace in this regard is
>>> that the solution is trivial.  :-)
>>   
>> No, of course Unix is not immune. Using <lf> or <cr> (Windows) as record
>> terminator is a rather silly idea. It means that you can't use those
>> characters in a record, and you have to scan the contents of a file for
>> those characters. Simply writing the length of a record at the beginning
>> of that record is far better solution.
> 
> Nearly every internet application protocol (HTTP, FTP, NNTP, SMTP) specifies
> <CR><LF> as the line terminator and nearly every unix-derived application
> screws it up at some point it its development.
> 
>                                                                   ---David Jones
> 

That's NETASCII.  It standardized the moving of text files and left it
up to the hosts on either end to ensure the file was in the format it
wanted.

bill