3

I have a bunch of PHP scripts that are in DOS format (vi displayed [noeol] [dos] in the status line) and as expected they weren't usable.

I ran dos2unix over them to fix the line endins:

dos2unix index.php

but when I open the files in vi I still see [noeol] on the status line.

Upon checking them in vi's hex editor mode (:%!xxd) I don't see anything that jumps out at me.

In the original files the line ends looked like: 0x0D 0x0A

If after running through dos2unix they look like: 0x0A

I also checked to ensure that the last line of the file has a proper end of line and that's there too (0x0A).

What else could be causing this, should I worry?

I'm running CentOS 5.6 x64.

Kev
  • 1,439

6 Answers6

5

As @Klox said, after running dos2unix, the remaining problem vi shows is the missing newline on the last line.

If you open the file in vi and save it, it will add the newline for you.

Or in a batch you can do the whole thing with ed:

#!/bin/bash
for f in <list-of-files-goes-here>; do
    ed -s -- "$f" <<<$',s/\r//g\nw' >/dev/null
done
enzotib
  • 51,661
2

It is just warning you that you don't have an end of line (\n) on the last line.

Klox
  • 401
1

DOS machines enter a carriage return at the end of lines (eol), it should look like this in vi ^M.

Try running this:

:%s/^M//g
nopcorn
  • 9,559
1

You may also use ed to batch convert your php files since ed will add the missing final newlines for you as well.

Using ed there is no need for tmp files either.

# using Bash
IFS=$'\n'
for file in *.php; do
   ed -s "$file" <<< $'H\n,g/\r*$/s///\nwq'
   #printf '%s\n' H $',g/\r*$/s///' wq | ed -s "$file"
done
tim
  • 11
  • 1
0

try this

find . -type f | xargs -I {} dos2unix {}

wdog
  • 101
0

If you use vim (instead of an old skool vi), you can do this:

:set ff=dos
:e!

and you'll be able to edit the PHP files without all the ugly "^M" suffixes. I believe it will save as a DOS "text file" format, too. This can be useful if you share the files with (ugh!) Windows somehow.

A little editorializing: the two-byte end-of-line token chosed for MS-DOS has got to have been one of the biggest problems that MS-DOS foisted off on the world, after segments, drive-letters and "\" as directory seperator. That two-byte token is still the reason for a difference between "text" and "binary". Ickk.