cannot display unicode char correctly

[noodlefighter]

I have read the issues about unicode, have known that linking libncursesw can solve those trouble.
but i think i find a new problem.

typing tig, it shows:

typing sudo tig, it shows:

./configure logging:

...
checking for working ncursesw/curses.h... yes
checking for working ncursesw.h... no
checking for working ncurses.h... yes
checking for tgetent... no
checking for tgetent in -lncursesw... yes
checking which library has the termcap functions... using libncursesw
...

check the libraries:

r@r-work ~/git/nkf $ ldd /usr/local/bin/tig
	linux-vdso.so.1 =>  (0x00007ffe765ca000)
	libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f9ec9594000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f9ec936b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ec8fa1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9ec8d9d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9ec97c3000)

r@r-work ~/git/nkf $ ldconfig -p | grep libncursesw
	libncursesw.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/libncursesw.so.5
	libncursesw.so.5 (libc6) => /lib/i386-linux-gnu/libncursesw.so.5
r@r-work ~/git/nkf $ sudo bash
r-work nkf # ldconfig -p | grep libncursesw
	libncursesw.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/libncursesw.so.5
	libncursesw.so.5 (libc6) => /lib/i386-linux-gnu/libncursesw.so.5

that is say, tig has link to libncursesw, but it display correctly in ROOT permission only..
have any idea? THX :)

[koutcher]

What about LANG and LC_* variables with and without sudo ?

[noodlefighter]

What about LANG and LC_* variables with and without sudo ?

Like this. look the same..

r@r-work ~/git $ locale 
LANG=zh_CN.UTF-8
LANGUAGE=zh_CN:zh
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=
r@r-work ~/git $ sudo locale
[sudo] password for r: 
LANG=zh_CN.UTF-8
LANGUAGE=zh_CN:zh
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=

[koutcher]

LOCPATH maybe ?

If it works for root, then the problem is not with tig. So it must be either one of the environment variables which is not retained by sudo or some files permissions.

[ted-dev-42]

after upgrading tig from 2.3 to 2.4.1, I got this issue too.
The difference is that 2.3 is installed by 'apt install' and 2.4.1 is built on the source code.
And comparing to the original one, my built tig is lack of "libreadline.so", not sure if this is the cause.

$ ldd ./tig
linux-vdso.so.1 (0x00007ffe95da1000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f8b2f5c0000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f8b2f396000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8b2efa5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8b2eda1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8b2fa91000)

$ ldd /usr/bin/tig
linux-vdso.so.1 (0x00007ffc8a54e000)
libreadline.so.7 => /lib/x86_64-linux-gnu/libreadline.so.7 (0x00007f2bf6483000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f2bf6254000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f2bf602a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2bf5c39000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2bf5a35000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2bf692e000)

[ted-dev-42]

UPDATE:
installed "libreadline-dev" then the issue is gone.

[Ferada]

> installed "libreadline-dev" then the issue is gone.

Yup, solved it for me too. Can that be checked in the configure script?

Edit: Can't reproduce this fix / problem.

[koutcher]

Unicode should work independendtly from readline. Readline's code to initialize locale is slightly different from tig's. I don't reproduce the problem on my machine, could you try to compile tig without readline and with the following patch ?

diff --git a/src/tig.c b/src/tig.c
index 25fd778..16a5de2 100644
--- a/src/tig.c
+++ b/src/tig.c
@@ -819,7 +819,7 @@ main(int argc, const char *argv[])
 		die("Failed to setup signal handler");
 #endif
 
-	if (setlocale(LC_ALL, "")) {
+	if (setlocale(LC_CTYPE, "")) {
 		codeset = nl_langinfo(CODESET);
 	}

[Ferada]

I can't reproduce the original problem after uninstalling libreadline-dev at all any more, also not in any constellation on a fresh Docker container, no idea.

[koutcher]

Could it be that while installing libreadline-dev the package manager fixed the permissions to the directory containing the locales definitions ? It could also explain why it works with root user for the OP.

[sruffell]

I thought I ran into this problem to, but after some head scratching, it turned out in my case that when run via sudo, I was using the version of tig installed from the package manager. When run as my local user, I was using the version I had just compiled....without the ncursesw library available.

[osa1]

I'm having a similar problem. tig from Ubuntu 18.04 repos can render my name correctly, but I just installed tig from the git repo (because it fixes a bug in tig --author=...) and it can't render my name:

Before:

After:

[marlun]

I'm having this problem when compiling myself as well.

~/src/tig(master=)$ tig --version
tig version 2.5.3
ncursesw version 6.1.20181013

LANG, LC_ALL and LC_LANG is "en_US.UTF-8".

[marlun]

Sorry for the noice, all I had to do was add the following in a config.make file (just as the INSTALL.asoc file says):

LDLIBS = -lncursesw
CPPFLAGS = -DHAVE_NCURSESW_CURSES_H

[koutcher]

Great that you got it working. Is there any reason why you didn't use configure ?

[marlun]

Only because using config.make was earlier in the documentation so it led be to believe it was the recommended way.

[koutcher]

Would that have been enough to make you use the configure script ?

--- a/INSTALL.adoc
+++ b/INSTALL.adoc
@@ -27,8 +27,8 @@ By default, `tig` is installed in `$HOME/bin`. To install `tig` elsewhere set
 Additional build options can be defined in the `config.make` file, which is
 loaded automatically when running `make` if it exists. By default,
 `contrib/config.make-$kernel_name` is loaded if it exists (currently only
-available for macOS [`Darwin`] and Cygwin). See `contrib/config.make` for
-example build options.
+available for macOS [`Darwin`] and Cygwin, Linux users should prefer the
+`configure` script). See `contrib/config.make` for example build options.
 
 Documentation files, such as manpages, are distributed in the release tarballs,
 and can be installed using:

[marlun]

Probably, yes :)

[shaicoleman]

Running the configure script fixed it for me.
Maybe there should be an error/warning when the configure script isn't run to avoid this issue, or automatically run configure in the autogen.sh script