[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