"Dmitry E. Oboukhov" <[email protected]> writes: > Greetings from the year 2026! > > I am writing to celebrate a truly historic milestone. I just checked > the 'fmt' utility in my fresh Debian system (version 9.7, copyright > 2025), and I am thrilled to see that this bug is still alive and well > after fourteen years of dedicated neglect. > > It is a rare feat in the software industry to maintain such consistent > incompetence. Your man page proudly displays "2025," yet the code > remains a pristine monument to the 1970s, incapable of understanding > that a single character might occupy more than one byte. > > Even an AI (which, by the way, is how many people discover your > "future-dated" tools now) can count characters better than 'fmt'. Is > the plan to wait until the 20th anniversary of this bug before you > consider using mbrtowc()? Or is the "GNU way" simply to ignore every > language on Earth that isn't English until the heat death of the > universe? > > I tried formatting Greek text (2 bytes per char), and 'fmt' broke the > lines exactly twice as often as it should. It's almost poetic: a tool > from the birthplace of modern logic being mangled by a tool that > refuses to use any. > > Please, don't fix it now. At this point, it’s not a bug—it’s a > heritage site. I look forward to checking in again in 2030 to see if > you've managed to reach the 8-bit era. > > Keep up the "stunning" progress. > Best regards, > > A user with a calendar and a multibyte keyboard.
Multi-byte character support has gradually been improving in coreutils recently. Regarding your "dedicated neglect" and "consistent incompetence" comments, note that all of the coreutils maintainers are employed to work on things other than coreutils. Perhaps you choose to work the rest of your waking hours, but that is quite rare of most people. Instead of being snarky on mailing lists, I encourage you to have a look at writing a patch. I will be happy to review it. Please make sure it handles incomplete and invalid multi-byte characters, includes tests, and performs well with LC_ALL=C. Thanks, Collin
