give me 27 as a result. Why might that be? I know here the blank spaces are counted as well; but there are just 4 of them. So that should be 26 instead of 27, right
Here I get the same discrepancy:
cat versuch.txt | tr -d [:blank:] | wc -m
Without the blank spaces, i.e. letters and comma and full-stop there should be 22 visible characters, but the result is 23.
Does anyone of you have any idea why the count doesn´t seem to be correct (one off)
Right, I got the same result.
I noticed two full-stops at the end here. Sure, this way it´s 23 instead of 22 visible characters.
Again a sign of newline perhaps…
The xxd command shows the hex representation on the left and text on the right. What looks like two dots at the end on the right is really 2e 0a in hex. That last character is a newline. In Windows you’d normally see a carriage return and line feed pair (13 10 decimal or 0D 0A in hex).
I thought it was kind of odd VI added the newline since I didn’t hit enter in the editor. I just typed in the text and saved it.
@Rosika Yes nl is a newline character. Also called linefeed , , or \n.
It counts as a character.
Files made in Windows have carriage return and linefeed… 2 extra characters.
It dates back to the days of teletypes
Quite.
I used featherpad for the creation of the text but otherwise did it just like you. Basically there shouldn´t have been a newline character, I guess.
Right you are.
Thanks for the confirmation.
I´ve now tried out the xxd command and indeed arrived at this:
The most precise solution would be to explicitly whitelist characters which are supposed to be counted. For example, whitelist all German characters, plus punctuation, etc. Then, you wou will get precisely the character count you are looking for.