Problems with special characters like äüö etc

[dinotheextinct]

Hello, I hope this issue is actually nnn related, but it only happens for me with said program.
How the folder and contents look with nnn

How it looks in dolphin

Its kind of weird because the names change also according to what you highlighted before, hard to explain I will try to provide a video if this info isn`t enough.

[jarun]

Either your nnn binary is not compiled with ncursesw OR you are using the make option -O_NOLC=1.

[dinotheextinct]

I used the package delivered with opensuse:

So I need to compile it myself to remedy the issue? Sorry not very technical or experienced.

[jarun]

What's the output of ldd $(which nnn)?

For example in my case it shows libncursesw:

$ ldd $(which nnn)       
	linux-vdso.so.1 (0x00007ffc81b81000)
	libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (0x00007fe8ea2e5000)
-->	libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007fe8ea2ab000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fe8ea27b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe8ea258000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8ea066000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe8ea060000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe8ea377000)

@Stig124 can you please have a look?

[dinotheextinct]

I am using fish shell if that makes any difference.

[jarun]

Ok, the binary is linked to libncursesw. Not sure if the package is built with NOLC.

I created a dir structure with äüö on Ubuntu (my custom build) and I can see everything fine:

[jarun]

@Stig124 in the PKGBUILD I see:

depends=('readline' 'ncurses')

should it be:

depends=('readline' 'ncursesw')

instead?

I am not sure though, because I see ldd lists ncursesw. Please have a look.

[jarun]

@dinotheextinct in the meantime, can you try the static binary available with the last release?

Or, if you are adventurous,

1. Clone this repo.
2. Run make strip // you may have to install gcc, make etc.
3. Run ./nnn and see if you still see the problem.

[dinotheextinct]

I can try to check the static binary later.

[signed-log]

@Stig124 in the PKGBUILD I see:

depends=('readline' 'ncurses')

should it be:

depends=('readline' 'ncursesw')

instead?

I am not sure though, because I see ldd lists ncursesw. Please have a look.

ncursesw is not a thing in Arch, for openSUSE might be a thing that I need to test, but have no time rn

@dinotheextinct try using the upstream repo instead of the openSUSE one link

[CantoroMC]

The ArchLinux pkg ncurses provide also /usr/lib/libncursesw.so

   |\_
  /o \\
 (_. ||
  /__\\
  )___( 

I have found this nice knight ascii art on the web, you may like to add it in front of the new nnn ascii art

[jarun]

Settled for

  |V\_
  /. \\
 (;^; ||
   /___3
  (___n))

[dinotheextinct]

@Stig124 in the PKGBUILD I see:

depends=('readline' 'ncurses')

should it be:

depends=('readline' 'ncursesw')

instead?
I am not sure though, because I see ldd lists ncursesw. Please have a look.

ncursesw is not a thing in Arch, for openSUSE might be a thing that I need to test, but have no time rn

@dinotheextinct try using the upstream repo instead of the openSUSE one link

Getting the following error when using your link

[jarun]

@dinotheextinct which release are you on? SLE/Tumbleweed/Leap?

I will download and share the package with you.

[dinotheextinct]

Tumbleweed

[jarun]

Here you go.

nnn-4.2-1.1.x86_64.rpm.zip

[dinotheextinct]

I appreciate the help, but I am not a big fan of downloading random archives from the internet. Can you tell me what exactly is different with this version? And is it possible to get those changes also in the distribution package for Opensuse TW?

[signed-log]

I appreciate the help, but I am not a big fan of downloading random archives from the internet. Can you tell me what exactly is different with this version? And is it possible to get those changes also in the distribution package for Opensuse TW?

Download the rpm directly from the repository website https://download.opensuse.org/repositories/home:/stig124:/nnn/openSUSE_Tumbleweed/x86_64/nnn-4.2-1.1.x86_64.rpm, I'll have to investigate why the repo is broken (shouldn't be)

[dinotheextinct]

Same problem with this package.

[jarun]

Please grab a static binary from here and confirm: https://github.com/jarun/nnn/releases/tag/v4.2

[0xACE]

Run

curl --dump-header headers -Lo 'nnn-4.2-1.1.x86_64.rpm' https://download.opensuse.org/repositories/home:/stig124:/nnn/openSUSE_Tumbleweed/x86_64/nnn-4.2-1.1.x86_64.rpm

then paste the headers file that gets created and give us the output of:

md5sum nnn-4.2-1.1.x86_64.rpm

The reason I'm asking is because it feels like your PC may be misconfigured

[dinotheextinct]

headers.tar.gz
md5sum nnn-4.2-1.1.x86_64.rpm 1330abe63bffc09af66198893ba33cd8 nnn-4.2-1.1.x86_64.rpm

[0xACE]

Same problem with this package.

Jesus my bad... when you said "Same Problem with this package" did you mean:

1. you couldn't download and install it?
   or
2. that it is also displaying broken characters?

Because it seems like you got the right package considering 1330abe63bffc09af66198893ba33cd8 is the correct hash... (Stig is the package compiled without sharedlibs?, i dont have the tools to extract a *.rpm)

Out of curiousity, if you cd to the directory in your screenshot and run pwd does it correctly display the path in your terminal? I've previously had characters failing to render because of a font config mishap...

[dinotheextinct]

I meant the second, same broken characters.

Uhm...doing pwd gives me the also weird characters. So I guess this means, the issue is not with nnn...? :(

[0xACE]

In this screenshot it seems fine:

Uhm...doing pwd gives me the also weird characters. So I guess this means, the issue is not with nnn...? :(

Out of curiousty: Where did it fail for you?

And yes, if your terminal isn't rendering your font correctly, nnn can't do much about it. the problem is in your environment. Best approach would be to talk to your distro and ask for help with your font config...

[dinotheextinct]

[0xACE]

that sort of reminds me about 10 years ago when i moved from windows to linux and i scp:ed my files from windows to linux. all non ascii filenames were corrupted just like that. So i guess it's better to actually try straight up: echo 'Aa Áá Bb Dd Ðð Ee Éé Ff Gg Hh Ii Íí Jj Kk Ll Mm Nn Oo Óó Pp Rr Ss Tt Uu Úú Vv Xx Yy Ýý Þþ Ææ Öö'

and maybe touch 'Aa Áá Bb Dd Ðð Ee Éé Ff Gg Hh Ii Íí Jj Kk Ll Mm Nn Oo Óó Pp Rr Ss Tt Uu Úú Vv Xx Yy Ýý Þþ Ææ Öö' and open nnn in the directory and see how it renders that filename and maybe see what ls says

my pc shows this:

[dinotheextinct]

The echo worked flawlessly, does this mean the font which my term is using actually works with this symbols, right?

When I open NNN it gives me some weird behaviour again.

Also I appreciate the help.

[dinotheextinct]

simplescreenrecorder-2021-08-26_18.05.20.mp4

Not sure how I can describe this, but for this has nothing to do with NNN. I just have 0 clue where this is coming from.

[dinotheextinct]

I feel like the echo also has some problems

[0xACE]

I'm guessing your environment is broken. Either your termcap is misconfigured or you are running nnn nested in another program that is making things complicated. or the magical chars are messing things up...

a quick test would be:

git clone https://git.suckless.org/st && cd st && make && ./st -e '/usr/bin/sh' '-ic' 'nnn /mnt/NVM2000/Musik'

I realize the problem with st termcap not installing but i expect it to behave better than your current environment. Sry i don't have time for this until next week as I will be away. If you can't wait until then: learn to debug your environment or contact your distro support group.

also maybe share your env and infocmp with us

[dinotheextinct]

`infocmp

Reconstructed via infocmp from file: /usr/share/terminfo/a/alacritty

alacritty|alacritty terminal emulator,
am, bce, ccc, hs, mc5i, mir, msgr, npc, xenl,
colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
dl=\E[%p1%dM, dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX,
ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l,
fsl=^G, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH,
ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n,
indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb:%p2%{255}%%{1000}%/%2.2X/%p3%{255}%%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\,
invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?,
kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8,
rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd,`

env SHELL=/usr/bin/bash SESSION_MANAGER=local/saurier:@/tmp/.ICE-unix/2319,unix/saurier:/tmp/.ICE-unix/2319 WINDOWID=73400322 KDED_STARTED_BY_KDEINIT=1 COLORTERM=truecolor XDG_CONFIG_DIRS=/home/dino/.config/kdedefaults:/etc/xdg:/usr/etc/xdg LESS=-M -I -R XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 GTK_IM_MODULE=cedilla MACHTYPE=x86_64-suse-linux G_BROKEN_FILENAMES=1 HOSTNAME=saurier HISTSIZE=1000 FROM_HEADER= MINICOM=-c on FREETYPE_PROPERTIES=truetype:interpreter-version=35 cff:no-stem-darkening=1 autofitter:warping=1 JAVA_ROOT=/usr/lib64/jvm/jre-openjdk JAVA_HOME=/usr/lib64/jvm/jre-openjdk JRE_HOME=/usr/lib64/jvm/java-11-openjdk-11 SSH_AUTH_SOCK=/tmp/ssh-Cbz2jbyoSoQa/agent.2146 CPU=x86_64 JAVA_BINDIR=/usr/lib64/jvm/jre-openjdk/bin XMODIFIERS=@im=local DESKTOP_SESSION=/usr/share/xsessions/default SSH_AGENT_PID=2215 GTK_RC_FILES=/etc/gtk/gtkrc:/home/dino/.gtkrc:/home/dino/.config/gtkrc XCURSOR_SIZE=24 GPG_TTY=/dev/pts/1 GTK_MODULES=canberra-gtk-module XDG_SEAT=seat0 PWD=/home/dino XDG_SESSION_DESKTOP=KDE LOGNAME=dino XDG_SESSION_TYPE=x11 MANPATH=/usr/local/man:/usr/share/man SYSTEMD_EXEC_PID=2138 XAUTHORITY=/run/user/1000/xauth_OSgwxo LS_OPTIONS=-N --color=none -T 0 XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/dino/.gtkrc-2.0:/home/dino/.config/gtkrc-2.0 XNLSPATH=/usr/share/X11/nls HOME=/home/dino SSH_ASKPASS=/usr/libexec/ssh/ssh-askpass LANG=en_DE.UTF-8 LS_COLORS= XDG_CURRENT_DESKTOP=KDE PYTHONSTARTUP=/etc/pythonstart OSTYPE=linux XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 QT_IM_SWITCHER=imsw-multi LESS_ADVANCED_PREPROCESSOR=no XSESSION_IS_UP=yes KDE_SESSION_UID=1000 LESSCLOSE=lessclose.sh %s %s XDG_SESSION_CLASS=user TERM=alacritty G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252 HOST=saurier XAUTHLOCALHOSTNAME=saurier LESSOPEN=lessopen.sh %s USER=dino KDE_SESSION_VERSION=5 MORE=-sl CSHEDIT=emacs DISPLAY=:0 SHLVL=1 WINDOWMANAGER=/usr/bin/startplasma-x11 PAGER=less QT_IM_MODULE=xim CVS_RSH=ssh XDG_VTNR=7 XDG_SESSION_ID=1 XDG_RUNTIME_DIR=/run/user/1000 DEBUGINFOD_URLS=https://debuginfod.opensuse.org/ QT_AUTO_SCREEN_SCALE_FACTOR=0 MANPATHISSET=yes XCURSOR_THEME=SpaceKCursors XDG_DATA_DIRS=/home/dino/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/share KDE_FULL_SESSION=true PATH=/home/dino/bin:/usr/local/bin:/usr/bin:/bin ALACRITTY_LOG=/tmp/Alacritty-3794.log DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus PROFILEREAD=true KDE_APPLICATIONS_AS_SCOPE=1 MAIL=/var/spool/mail/dino HOSTTYPE=x86_64 LESSKEY=/usr/etc/lesskey.bin _=/usr/bin/env

[jarun]

If you see #1145 (comment) when the user changed the locale to en_US, the characters were not visible. Can you check if it's a locale issue for you as well?

[dinotheextinct]

locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_DE.UTF-8 LC_CTYPE="en_DE.UTF-8" LC_NUMERIC="en_DE.UTF-8" LC_TIME="en_DE.UTF-8" LC_COLLATE="en_DE.UTF-8" LC_MONETARY="en_DE.UTF-8" LC_MESSAGES="en_DE.UTF-8" LC_PAPER="en_DE.UTF-8" LC_NAME="en_DE.UTF-8" LC_ADDRESS="en_DE.UTF-8" LC_TELEPHONE="en_DE.UTF-8" LC_MEASUREMENT="en_DE.UTF-8" LC_IDENTIFICATION="en_DE.UTF-8" LC_ALL=

I guess first three rows dont look good. ^^;

[dinotheextinct]

Jesus christ, I think I fixed it, I deleted: ~/.config/plasma-localerc

Beautiful. Thanks for all the help guys and for this great software, much love!

[jarun]

Glad to know this is fixed!