getting valid line counts

[punchykool]

I have what appears to be a user error, but I cannot determine why the results are not coming out right.

I have a file with 90 validated lines in it.
//I counted them manually

Using `wc -l`, it yields 89.
I look for lines with the string "A" in it and get 79.
//The prompt returns on a newline
I look for lines with the string "B" in it and get 8.
//The prompt returns on a newline
I look for lines with the string "C" in it and get 2.
//Here the prompt does not return on a newline


In reality, there are really 3 lines with "C" in it.
The resulting sets equal the total, so that matches up, but still the missing "C" record is not returned nor included in the total count?

I have converted the file using dos2unix to remove the newline chars. I even viewed the hidden chars in the file using vi and the ':set list' modal, but I do not see anything but the dollar sign at the end of each line. There are no blank lines in the file either nor any stray characters out of view. Dumping the file to the screen with `cat`, I see that on the last record, it does not get a newline on the screen, so the prompt is placed at the end of this record? I am seeing this behavior in several other similar files with similar origins.
I am using SunOS 5.6.

Any help, suggestions appreciated. I have seen this happen over the years and had no time to investigate. I simply had to do the math longhand in the files :-|

 

[olded]

Hi:

When you first vi the file, how many lines does it say are in the file? It should be at the bottom of the screen along with the filename.

In certain cases, I've seen the DOS end of file marker, octal 32, not get deleted with the dos2unix command. Could this be your issue? In my file transfers from DOS, I don't rely on dos2unix. I use this:

tr -d '\015\032' < mydosfile

Regards,


Ed

 

[punchykool]

Well, I had not noticed the message at the bottom of vi in this case, Ed. It reads:

"myfile.txt" [Incomplete last line] 90 lines, 7339 characters

90 is indeed how many lines reside in the file.
What is it complaining about do you suppose?

I tried your translation command and wrote it to another file.
tr -d '\015\032' <myfile.txt >myfile.txt_ED

I opened myfile.txt_ED in vi and it reads the same message at the bottom of the screen as my original file so I don't think that it effected a change, or at least any difference than mine.
Any other ideas without actually seeing the file for yourself?

 

[PHV]

Seems that the last line doesn't have a LF.
Simply do this:
echo "" >> myfile.txt_ED

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[olded]

Interesting. I've seen this happen a few times where the last line gets garbled. With that "incomplete last line", it could be anything. Perhaps the last line isn't terminated with an EOL?

Have you tried executing:

od -c myfile.txt

You should see \n at the end of each line.

Regards,


Ed

 

[punchykool]

Ed,
The octal dump did not print the newline char at the end of each line. There were newlines in the output, but not at the end of each line.

PHV,
Your solution of appending a newline to the file worked, although I am confused how that line feed worked and what causes this.

 

[olded]

Hi:

Essentially, PHV just appended a LF.

You can recreate this with a stupid programming trick:

#include <stdio.h>

/* stupid programming trick */
int main(void)
{

printf("%s\n", "line 1");
printf("%s\n", "line 2");
printf("%s", "line 3");

}

The above "C" stub will create a file with the last line not having a LF. Simply compile the program, execute it and redirect the output to a file. You'll get the same 'incomplete last line' warning when entering vi.

Regards,


Ed

 

[punchykool]

ahhhhh.
that makes sense. thanks for the explanation.