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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 13 May 2026 19:16:22 +0000 (UTC)
    From:        riastradh%NetBSD.org@localhost
    Message-ID:  <20260513191622.E29161A923A%mollari.NetBSD.org@localhost>

  | 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 @netbsd.org
e-mail addr if you have one, and anything not @gmail.com otherwise (off
list) and I will send you a copy.


  | 2. If started with LC_CTYPE=C, entering � moves the cursor to the
  |    beginning of the line but does not delete it:
  |
  | 	$ echo 
  |                ^
  |    transitions, on entering � (i.e., octets 0xc2 0xa3), to
  |
  |         $ echo
  |           ^
  |    where ^ 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!  all
real unix users use vi mode, emacs is for VMS TOPS TENEX (etc) users,
where "one giant lump of goo which pretends to do everything" is SOP :-).

There 0xc2 0xa3 is likely to be interpreted as Meta-B Meta-#  As best
as I can follow emacs mode key bindings, Meta-B (and Meta-b) is "backward
word" (which corresponds with what you indicated happened), and I believe
that Meta-# isn't bound to anything at all (so would probably just be
ignored).

  |    (This is a change from before, when the input was apparently just
  |    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 libedit)
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 "cooked" 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 settings
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 appears.


Lastly, for anyone who cares, very little of this change will affect SMALL
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 look
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