[PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano]

Hi Corinna,

On Tue, 8 Sep 2020 10:40:34 +0200
Corinna Vinschen wrote:
> On Sep  7 13:45, Takashi Yano via Cygwin-patches wrote:
> > On Mon, 7 Sep 2020 01:04:13 +0900
> > > > Chages:
> > > > - If global locale is set, it takes precedence.
> > > 
> > > Changes:
> > > - Use __get_current_locale() instead of __get_global_locale().
> > > - Fix a bug for ISO-8859-* charset.
> > 
> > Changes:
> > - Use envblock if it is passed to CreateProcess in spawn.cc.
> 
> For the time being and to make at least *some* progress and with my
> upcoming "away from keyboard"-time , I pushed the gist of my patch,
> replacing the locale evaluating code in fhandler_tty with the function
> __eval_codepage_from_internal_charset in its most simple form.
> I didn't touch anything else, given that this discussion is still
> ongoing.

Your patch pushed does the magic!

Even cygterm works even though the code does not check environment.

The point is here.

@@ -1977,9 +1807,6 @@ fhandler_pty_slave::fixup_after_exec ()
   if (!close_on_exec ())
     fixup_after_fork (NULL);   /* No parent handle required. */

-  /* Set locale */
-  setup_locale ();
-
   /* Hook Console API */
 #define DO_HOOK(module, name) \
   if (!name##_Orig) \

Without this deletion, term_code_page is determined when
cygwin shell is executed. Since it is in fixup_after_exec(),
setlocale() does not called yet in the shell. As a result,
term_code_page cannot be determined correctly.

In your new patch, term_code_page is determined when the first
non-cygwin program is execed in the shell. The shell process
already calls setlocale(), so term_code_page can be determined
using global locale.

Thanks for the excellent idea!

Only the problem I noticed is that cygterm does not work if the
shell does not call setlocale(). This happens if the shell is
non-cygwin program, for example, cmd.exe, however, it is unusual
case.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>