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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: riastradh%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/58609 (sh(1) ignores interactive locale changes)
Date: Fri, 15 May 2026 00:35:14 +0700

     Date:        Wed, 13 May 2026 19:16:22 +0000 (UTC)
     From:        riastradh=40NetBSD.org
     Message-ID:  <20260513191622.E29161A923A=40mollari.NetBSD.org>
 
   =7C Synopsis: sh(1) ignores interactive locale changes
 
 I have undated my source tree for that change (which hadn't been touched
 in well over a year) to be consistent with what is in HEAD now, and
 while I haven't checked line by line, the diffs I see look to be more
 or less the same as the ones you posted.
 
 If everyone is happy with me doing so, I will commit that to /bin/sh
 in HEAD soon (you may have noticed the total lack of any sh.1 update,
 which is clearly required, I had been deferring that until there was
 some confidence that the code as is was acceptable, to avoid documenting
 something that wasn't going to remain).   That will take a few days
 (at least), so there is time for people to investigate still.
 
 If anyone would like the patches for HEAD, send me your =40netbsd.org
 e-mail addr if you have one, and anything not =40gmail.com otherwise (off=
 
 list) and I will send you a copy.
 
 
   =7C 2. If started with LC_CTYPE=3DC, entering =A3 moves the cursor to t=
 he
   =7C    beginning of the line but does not delete it:
   =7C
   =7C 	=24 echo=20
   =7C                =5E
   =7C    transitions, on entering =A3 (i.e., octets 0xc2 0xa3), to
   =7C
   =7C         =24 echo
   =7C           =5E
   =7C    where =5E indicates the position of the cursor on the line above=
 .
 
 This is all libedit, not sh, about which I am certainly no expert.
 
 But from that, I'd guess you're in emacs editing more   (shame=21  all
 real unix users use vi mode, emacs is for VMS TOPS TENEX (etc) users,
 where =22one giant lump of goo which pretends to do everything=22 is SOP =
 :-).
 
 There 0xc2 0xa3 is likely to be interpreted as Meta-B Meta-=23  As best
 as I can follow emacs mode key bindings, Meta-B (and Meta-b) is =22backwa=
 rd
 word=22 (which corresponds with what you indicated happened), and I belie=
 ve
 that Meta-=23 isn't bound to anything at all (so would probably just be
 ignored).
 
   =7C    (This is a change from before, when the input was apparently jus=
 t
   =7C    ignored.)
 
 Might that have been vi mode?  vi-mode is unlikely to have any bindings
 for input with the top bit set in the C locale, so everything non-ascii
 is most likely just ignored.   Nothing I am aware of (including to libedi=
 t)
 has changed any way which should have altered anything like that.
 
 
 But for more details on that, you need confirmation from someone who
 understands libedit lots better than I do.  sh doesn't get involved
 until you have told libedit that you are done with the input (most often
 by entering a newline).   If you had libedit turned off, then it would be=
 
 the tty driver doing the editing, until you finish a line (when not using=
 
 libedit sh reads from stdin without doing anything special, the tty would=
 
 be left in =22cooked=22 mode.)
 
 
 One other issue (since there is no doc to read yet), when the LC_CTYPE
 changes in sh, it tells libedit about that by disabling it, and then
 re-initing again (at which point libedit sees the updated locale settings=
 ).
 What that means, I believe (and again I guessing a bit about libedit) is
 that any local bindings or settings that were made since the last libedit=
 
 init would be lost at that point, and need to be done again.   (The setti=
 ngs
 config file would be re-read though I think, so more permanent changes
 would be retained).   I doubt many people make use of libedit's command
 mode when entering sh input, but if you do, beware, after this change app=
 ears.
 
 
 Lastly, for anyone who cares, very little of this change will affect SMAL=
 L
 shells, none of the locale manipulations will be added to one of those
 (SMALL shells are typically found in limited space boot media, if you loo=
 k
 at the value of sh's NETBSD_SHELL variable, and see SMALL in there, then
 you are in a SMALL shell) - there are some required changes to more basic=
 
 parts of the shell, so even a SMALL shell will grow a little with this
 change though (I have not yet measured how much - though the answer would=
 
 also depend upon the various architectures).
 
 kre