Mercurial > hg
view tests/test-wireproto-command-known.t @ 44261:04a3ae7aba14
chg: force-set LC_CTYPE on server start to actual value from the environment
Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can
cause issues with chg being able to start up. D7550 attempted to fix this, but a
combination of a misreading of the way that python3.7 does the coercion and an
untested state (LC_CTYPE being set to an invalid value) meant that this was
still not quite working.
This change will cause differences between chg and hg: hg will have the LC_CTYPE
environment variable coerced, while chg will not. This is unlikely to cause any
detectable behavior differences in what Mercurial itself outputs, but it does
have two known effects:
- When using hg, the coerced LC_CTYPE will be passed to subprocesses, even
non-python ones. Using chg will remove the coercion, and this will not
happen. This is arguably more correct behavior on chg's part.
- On macOS, if you set your region to Brazil but your language to English,
this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If
this value is passed along when ssh'ing to a non-macOS machine, some
functions (such as locale.setlocale()) may raise an exception due to an
unsupported locale setting. This is most easily encountered when doing an
interactive commit/split/etc. when using ui.interface=curses.
Differential Revision: https://phab.mercurial-scm.org/D8039
author | Kyle Lippincott <spectral@google.com> |
---|---|
date | Wed, 29 Jan 2020 13:39:50 -0800 |
parents | a732d70253b0 |
children |
line wrap: on
line source
$ . $TESTDIR/wireprotohelpers.sh $ hg init server $ enablehttpv2 server $ cd server $ hg debugdrawdag << EOF > C D > |/ > B > | > A > EOF $ hg log -T '{rev}:{node} {desc}\n' 3:be0ef73c17ade3fc89dc41701eb9fc3a91b58282 D 2:26805aba1e600a82e93661149f2313866a221a7b C 1:112478962961147124edd43549aedd1a335e44bf B 0:426bada5c67598ca65036d57d9e4b64b0c1ce7a0 A $ hg serve -p $HGPORT -d --pid-file hg.pid -E error.log $ cat hg.pid > $DAEMON_PIDS No arguments returns something reasonable $ sendhttpv2peer << EOF > command known > EOF creating http peer for wire protocol version 2 sending known command response: [] Single known node works $ sendhttpv2peer << EOF > command known > nodes eval:[b'\x42\x6b\xad\xa5\xc6\x75\x98\xca\x65\x03\x6d\x57\xd9\xe4\xb6\x4b\x0c\x1c\xe7\xa0'] > EOF creating http peer for wire protocol version 2 sending known command response: [ True ] Multiple nodes works $ sendhttpv2peer << EOF > command known > nodes eval:[b'\x42\x6b\xad\xa5\xc6\x75\x98\xca\x65\x03\x6d\x57\xd9\xe4\xb6\x4b\x0c\x1c\xe7\xa0', b'00000000000000000000', b'\x11\x24\x78\x96\x29\x61\x14\x71\x24\xed\xd4\x35\x49\xae\xdd\x1a\x33\x5e\x44\xbf'] > EOF creating http peer for wire protocol version 2 sending known command response: [ True, False, True ] $ cat error.log