There seems to be a little bit of a language barrier. With this example, I now understand what you were saying in your first message in this thread.

The sed utility (and most editors and text processing utilities meant to run on most UNIX and Linux systems) only have defined behavior when the input file is a text file. In particular sed commands work on input lines. When the input file contains text that is not terminated by a <newline> character (or as you said "doesn't has enter in the end of line"), the input is not a text file because it does not end with a <newline> character. By definition, a line ends with a <newline> character. The sed utility isn't processing the last "row" in your input file because it is not a line. As zaxxon has pointed out, this will work on some systems, but the standards do not require it to work.

On many versions of vi, if you try to edit a file that is missing the terminating <newline> character with the command:

Code:

vi aaa.txt

the status line at the bottom of the screen when you open the file will show something like:

Code:

"aaa.txt" [noeol]

meaning it did not find an End-Of-Line character at the end of the file. If you then enter the command :w followed by hitting the Enter (or return or carriage-return) key on your keyboard, vi will then add the missing <newline> character to the end of the file and sed will work as you expect.

If you have a list of files that you know are missing the trailing <newline>, you could also do something like:

Code:

for f in filename1 filename2 ...
do      echo >> "$f"
done

where filename1, filename2, and ... are replaced by the names of the files you want to fix. If you give this script the name of a file that already has a <newline> at the end of the file, it will add an empty line to the end of the file.