Hello LuX,
As you know I don't use a UTF-8 system at this moment so I can't verify myself if my nano UTF-8 compliant is really UTF-8 compliant :)
But I've found a solution at your problem.

Some search learn me that we can compile ncurse with wide character support by adding the "--enable-widec" compile command, I explain you how I've compiled that on my Slitaz :

The first thing to do is to download the Slitaz cooking wok :

tazpkg get-install mercurial
hg clone http://hg.slitaz.org/wok/ /home/slitaz/wok-slitaz

(note : I download it in home/slitaz/wok-slitaz because I don't want to overwrite the receipt I create in home/slitaz/wok)

Then I copy receipts and stuffs for nano and ncurses in my own wok :

cd /home/slitaz/wok-slitaz
cp -a nano ncurse* ../wok

At this step, if I compile nano (in Slitaz it's the version 2.0.9) I obtain the same error about UTF-8 support. Note : recompile C library seems hard to me, so I've tried to recompile ncurses first hopping to solve the problem.

I add the wide characters support in ncurses : I add --enable-widec compile command, then the compile rules in ncurses receipt is :

# Rules to configure and make the package.
compile_rules()
{
    cd $PACKAGE-$VERSION
    sed -i 's|\tsh $(srcdir)/MKhashsize.sh|\tash $(srcdir)/MKhashsize.sh|' \
    	include/Makefile.in
    ./configure --prefix=/usr \
    --libdir=/lib --sysconfdir=/etc \
    --infodir=/usr/share/info --mandir=/usr/share/man \
    --with-shared --without-debug --without-ada \
    --enable-widec \
    $CONFIGURE_ARGS &&
    make &&
    make DESTDIR=$PWD/_pkg install
}

I cook ncurses :

tazwok cook ncurses

I reinstall ncurses and ncurses-dev :

tazpkg install /home/slitaz/packages/ncurses-5.7-dev.tazp
kg --forced
tazpkg install /home/slitaz/packages/ncurses-dev-5.7-.taz
pkg --forced

I cook nano :

tazwok cook nano

And there's no more UTF-8 error, so I guess it solve your problem. I let you make the tests and tell me if it's ok.

Note : the officials Slitaz packages, as vte, are cooked with the ncurses wich don't have wide characters support enable. Maybe we must recompile them to have good results and solve somes terminal problems for exemple. I will try to install a UTF-8 system for more tests.

Hi,

Gokhlayeh is right, we need a ncursesw package and rebuild all ncurses apps who can do UTF-8. I'm working on this and still have to make some choice and testing before pushing to SliTaz repos.

Hello,

@ Go Khla Yeh: this sounds great! I will try it tonight.

Sheers,
LuX.

Hello,

I've just tried it, with two little differences :

- I haven't cloned the online wok, because my 20Go HD is almost full at the moment, and since I won't change it for a while I have to be very carefull not to fill it up definitely. Since ncurses was installed I simply copied its receipt from /var/lib/tazpkg/installed. I hope this doesn't mind.

- Instead of installing my own ncurses with the --forced option, I first removed the installed one with "tazpkg remove ncurses" and then installed the cooked package with "tazpkg install".

Surprisingly enough, although the compilation seems to have worked properly (it was very long and produced a huge list of messages, but I suppose that it is normal) the result is drasticly different: no terminal at all is working now, and nano (in tty) doesn't work either because, as is written in boot.log (and running nano produces the same message):

/usr/bin/reset: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

Indeed the only remaining libncurses* files outside /home are /lib/libncurses++w.a and /lib/libncurses.a, which come from ncurses-dev, I think. The missing libraries libncursesw.so* exist however, they are still in /home/slitaz/wok/ncurses/ncurses-5.7/lib. These is probably due to the fact that the receipt contains the following lines, which were written for the official ncurses package, whose libraries are libncurses.so* (no 'w' at the end):

    # Libs.
    cp -a $_pkg/lib/libncurses.so* $fs/lib
    strip --strip-unneeded $fs/lib/*.so*

I have tried to copy by hand the libncursesw.so* libraries from /home to /lib but it did not change anything: neither xterm nor any terminal work, apparently because they require libncurses.so*, which is logical since they were compiled for ncurses without --enable-widec. This is probably what Pankso had in mind when he wrote:

* Pankso has written
we need a ncursesw package and rebuild all ncurses apps who can do UTF-8.

A temporary solution would be to fix the new receipt of ncurses, and then recompile every program depending on it. Huh! I suddenly feel a little bit lazzy. I think I will simply remove my ncurses, re-install the official one and... go to bed.

Best regards,
LuX.

Hi,

Work in progress, just commited ncursesw packages (nano, dialog and more will follow): http://hg.slitaz.org/wok/rev/64cf592b6880

Some package using ncurses libs dont support wide char, so ncurses and ncursesw will be both installed by default. Since the 2 package use same terminfo and tabset I splited ncurses to have ncurses-common.

- Christophe

Hello Pankso/Christophe,

Great work, thank you very much!

Et maintenant, dodo ! :-)
LuX.

bonne nuit...

not too sure whether this is related (i think so), but i get problems listing files with names in another language. BUT if i ssh in to slitaz from another box that's fine, the filenames display properly in that terminal...

Hello jf_

if your file names are encoded in UTF-8 (which is plausible) and you use an OS with Latin1 encoding OR list your files in a terminal which doesn't support UTF-8 encoding like xterm, non-ascii caracters won't be displayed properly. This is normal.

Note that if you read the content of these files in the terminal, with less, vi, nano, and so on, you will have the same problem.

On the other hand if you connect to Slitaz from another computer using UTF-8 encoding and an UTF-8 compliant terminal like uxterm, urxvt, xfce4-terminal, vte-terminal, lxterminal, and so on, you won't have any problem since the terminal you are using matches the encoding of your files.

Sheers,
LuX.