[vox-tech] Problems with missing 'missing' file

Shwaine shwaine at shwaine.com
Thu Jun 23 13:19:51 PDT 2011



On Wed, 22 Jun 2011, Rick Moen wrote:

> Quoting Shwaine (shwaine at shwaine.com):
>
>> Assuming that the \r is actually carriage return (and not a literal string
>> consisting of backslash and the letter r) and that this was originally an
>> older Mac formated file, you probably don't want to remove \r.
>
> I actually meant exactly what I typed, i.e., the backslash as an escape,
> followed by a character 'r'.  That's the way you refer to an ASCII 13
> carriage return control character in vim search strings.  Line feed
> would be \n.  Attempt to insert an actual CR into a vim ex-mode search
> string, and you won't get the result you had in mind.
>

And nothing about my reply contradicted this. In fact, my reply was just 
clarifying that the old Mac file format is just carriage return (\r) and 
not carriage return-line feed (\r\n) like the Windows format. This means 
that the vim substitution command to correct the Mac file format is NOT 
the same as the substitution command for correcting Windows file format.

The other purpose of my reply was to give the correct vim substitution 
command, which is counter-intuitive since it changes the meaning of \r in 
the replacement string. My substitute command still used \r in the search 
string, if you happened to overlook that. The meaning of \r and \n in vim 
substitution varies depending on whether you are in the search string or 
the replacement string. In the search string, yes, it has the standard 
meaning. In the replacement string? Not so much. Not many people know that 
and my reply was meant to clarify the difference.

<snip>
>
> The only slow bit is arguing with obsessives on mailing lists.  ;->
>

Frankly, I don't see what was so controversial as to warrant such a long 
reply, and particularly not this last line in your reply. Most people 
would have naively tried

:%s/\r/\n/g

to convert carriage returns into line feeds and then would have been 
perplexed when that resulted in ^@ (vim display for null character) being 
inserted rather than having the carriage returns replaced with line feeds. 
Then they probably would have done :q! and used dos2unix anyways, instead 
of realizing the problem is the new meaning of \r and \n in the 
replacement string.

What's so obsessive about giving people the correct information (nature of 
old Mac file formats) and giving them a few tools (the correct vim 
substitution command, vim file format command and tr command) to correct 
the problem?


More information about the vox-tech mailing list