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

[Shwaine]

On Wed, 22 Jun 2011, Rick Moen wrote:

> Quoting Eric Lin (notapplicable.haha at gmail.com):
>
>> On Wed, Jun 22, 2011 at 03:43:54PM -0700, Cam Ellison wrote:
>>> I'm trying to compile a firmware flashing app (I have a MultiTech modem
>>> with a motorboating problem, and the firmware upgrade is said to be the
>>> answer) and keep running into the same error.  The app was developed for
>>> OSX, but the notes say it will run on Linux.
>>
>>> I have seen a suggestion that running dos2unix will deal with those
>>> $'\r' lines, but dos2unix thinks it's a binary file.
>>
>> I downloaded the source for this app and ran dos2unix on all the files.
>> Afterward, I had to modify a few of the source files' headers to get it
>> to actually compile. Also, I have automake-1.11, but make wanted
>> automake-1.10 and aclocal-1.10, so I just made symlinks in my ~/bin
>> folder.
>
> You know, it's really worthwhile getting to know how to do
> search/replace for such problems within vim.  For one thing, if you try
> such a change and it doesn't seem to have worked correctly, you can just
> do 'u' to undo, and try to refine your change.
>
> In this case, something like
>
> :%s/\r//g
>
> is probably all you needed.  That's
>
> :  enters ex-type command mode
> %  sets scope to all lines
> s  search & replace
> /  delimiter ahead of spec to search for
> \r spec to search for
> /  delimiter behind spec to search for and ahead of replacement spec
> /  delimiter behind replacement spec (i.e., replacement spec is null, here)
> g  and make the change globally, not just once.
>
> You can of course do the same operation in 'sed', but doing it inside
> the vim buffer gives you that ever-handy quick reversion.
>

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. Older Mac 
files only have a carriage return to mark the end of line and do not have 
a line feed (\n, the end-of-line delimiter on Unix/Linux). So if you 
remove the carriage returns on an old Mac file, you end up with one very 
long line.

Better to check if there are line feeds to decide if you need to remove 
the carriage returns or replace them with line feeds. You'll know pretty 
quickly after opening it in vim if there's line feeds or not. If the file 
appears as one big long line with ^M where line breaks should be, there's 
no line feeds and you'll need to replace \r with \n.

There's a couple ways to go about replacing. The vim substitute command is 
actually a little counter-intuitive in this case. In the search field of 
the substitute command, \r means carriage return and \n means line feed, 
but, in the replacement field, \r means "new line" for the current file 
format and \n means the null byte. So your substitute command should 
actually look like this (which seems odd at first glance if you don't 
know the difference between the special strings in both fields):

:%s/\r/\r/g

If you're using vim and it understands the Mac file format, you can just 
give the following:

:e ++ff=mac

My favorite of course is to use tr:

cat <filename> | tr '\r' '\n' > <filename>

Or you can just use dos2unix. If you have a large number of files to 
convert, dos2unix (or writing your own script to parse the source 
directory and call tr on each file) works well.