John P. Linderman wrote in : |On Thu, Mar 11, 2021 at 4:18 PM Steffen Nurpmeso \ |wrote: |> John P. Linderman wrote in |> : |>|The tab/detab horse was still twitching, so I decided to beat it a little |>|more. |>| |>|Doug's claim that tabs saving space was an urban legend didn't ring true, |>|but betting again Doug is a good way to get poor quick. | |> Not really. I mean, i do not insist of this, but i looked at the |> numbers. And despite col(1) 2.36.2 giving the wrong line when |> failing to dig a LATIN1 in UTF-8 (should be 7, gave 11), when |> i sum up the total of 8: in an old project with tests, |> documentation etc. here the output is 1044401. This is without |> generated data. | |I'm not certain what you are referring to by "Not Really". But there is a I am sorry. It must have been bad english and a misunderstanding. Especially surrounding the dead horse that was mentioned in the original message of yours. |general issue about the ability of historical commands (like "ed") to |properly handle unicode. I would expect that many early commands do very |poorly. -- jpl Yes. Of course. It is one of these days were whatever i do i stumble over errors in my own as well as in other peoples software, and then this script of years was a nice try (i never actually did that test), and then the find(1) i did spit out masses of errors, and it took quite some trials to get it done. I apologise. Just one of these days. $ echo Müßig | iconv -f utf8 -t latin1 | LC_ALL=C col -x col: failed on line 1: Invalid or incomplete multibyte or wide character This should not happen. (Now also clarified by POSIX standard.) #?1|kent:tmp$ cat <<_EOT | iconv -f utf8 -tlatin1 | LC_ALL=C col -x one two three four five älter _EOT col: failed on line 11: Invalid or incomplete multibyte or wide character one two three four five No fun for me today. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)