D8039: chg: force-set LC_CTYPE on server start to actual value from the environment
yuja (Yuya Nishihara)
phabricator at mercurial-scm.org
Thu Jan 30 12:02:46 EST 2020
yuja added a comment.
> What do you think about this approach:
> 1. The server detects that LC_TYPE is coerced.
> 2. When handling the "validate" command, the server sends back "invalidate this server, and fallback to original hg" response.
> This makes chg/non-chg behave consistently with some startup overhead in mis-configured environment. The chg client can potentially print a warning to remind the user to fix their environment.
That could be, but if we do want to make chg/hg behavior consistent, maybe we
can adjust the hash computation logic?
1. client sends CHG_ORIG_LC_CTYPE or CHG_UNSET_LC_CTYPE when spawning server
2. they're kept in environ dict, but override LC_CTYPE while computing hash, and excluded from the hash
3. client does not send these variables over setenv command, but passes the validation because `{CHG_ORIG_LC_CTYPE: x, LC_CTYPE: y} == {LC_CTYPE: x}`.
If we had a sha1 logic in C, we could compute the env hash at client side.
Python 3 can't be trusted.
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST ACTION
https://phab.mercurial-scm.org/D8039/new/
REVISION DETAIL
https://phab.mercurial-scm.org/D8039
To: spectral, #hg-reviewers
Cc: quark, yuja, mjpieters, mercurial-devel
More information about the Mercurial-devel
mailing list