Re: bin/58609: sh(1) ignores interactive locale changes

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR bin/58609; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/58609: sh(1) ignores interactive locale changes
Date: Fri, 16 Aug 2024 20:31:58 +0000

 > Date: Sat, 17 Aug 2024 03:06:32 +0700
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 >=20
 >     Date:        Fri, 16 Aug 2024 17:30:01 +0000 (UTC)
 >     From:        campbell+netbsd%mumble.net@localhost
 >     Message-ID:  <20240816173001.A3B3B1A9244%mollari.NetBSD.org@localhost>
 >=20
 >   | If you start sh(1) with LC_CTYPE=3DC, when you enter UTF-8 input,
 >   | sh(1) will ignore it, as one might expect.
 >=20
 > That makes no sense to me at all ... sh(1) really knows close to nothing
 > about locales (though it should know a little more than it does) and does
 > nothing (except some pattern matching) differently at all based upon what
 > the locale is set to.   Characters are simply sequences of bytes, sh does=
 n't
 > care what they represent, if you echo one of them (however many bytes the=
 re
 > are) sh's echo will simply write them out as entered.
 >=20
 > Please try again after turning line editing off (set +VE) - if that makes
 > a difference, then it is libedit you're having an issue with.  sh should
 > not be "ignoring" whatever that means, anything input, except '\0'.
 
 I tried that and now I can type in the input.  (And then when I delete
 successive characters backward, it backs over the last character of my
 prompt, a space.  But I assume that's the pty driver or terminal
 emulator's doing, not anything to do with sh(1) or libedit.)