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.y...@nifty.ne.jp>
