bug#45093: Character 149 causing ASCII BEL output to console in Windoze port of Gnu CoreUtils

[Robert S. Kissel]

Gentlemen:

To reproduce (on Windoze):

perl -e "print chr(149)" | head
perl -e "print chr(149)" | tail
perl -e "print chr(149)" | cat
perl -e "print chr(149)" | grep -v abc

I'm pretty sure this is a bug in the Windoze port of head and tail,
and it is also in grep and probably a number of other programs where I
haven't encountered it yet. It ONLY beeps if it is sent to the
CONSOLE.  If the output is further piped into a file, the character is
written as a single MW character (195 decimal, 95 hex).  In other
words,

perl -e "print chr(149)" | head >output.txt

will not corrupt the character or change it to an ASCII BEL character.

Versions I'm using:

head/tail (GNU coreutils) 5.3.0
Written by David MacKenzie and Jim Meyering.
Copyright (C) 2005 Free Software Foundation, Inc.

cat (GNU coreutils) 5.3.0
Written by Torbjorn Granlund and Richard M. Stallman.

GNU grep 2.5.4
Copyright (C) 2009 Free Software Foundation, Inc.

Windows 7 "Ultimate" on a PC; cmd console.

Character 149 is a Unicode C1 control character MW or "MESSAGE
WAITING" character, but is turning into a C0 BEL character (character
7) by mistake.

I noticed this when I was working with Chinese text encoded in UTF-8.
Just outputing character 149 to the console in Windoze with another
program does NOT produce this queer effect of "playing" character 7,
the ASCII BEL.

It's quite devastating--the machine and software are fast, and the
screendump ends up freezing the console and making it impossible to
interrupt with any sort of kill signal--one may only wait an hour for
the beeping to stop, or else terminate the console window itself and
open a fresh one.

I have no idea why this should be happening--but I would appreciate it
if you'd reproduce it, now that I've narrowed down exactly WHICH byte
is causing this effect--or else tell me if I'm zillions of versions
behind or if this is a known problem with the Windoze console that has
nothing to do with the software (but then I don't understand why other
programs don't mimic this behavior).

Many thanks in advance for your attention.

Very truly yours,
Robert S. Kissel
Hamden, Connecticut
U.S.A.