Perhaps it would help if you actually told us why it’s a partial solution.
As far as I can remember, this is the first time the TERM variable has noticeably affected anything other than the terminal for me.
Anyway, probably best to go back to the devs and see if they can fix it for other values of TERM, especially if they used to work.
To be specific the selection prompt is failing immediately, due to the TERM variable. If you press q at the prompt then you get the same “failed:” error.
It’s only a partial solution because when launching custom applications from a drawer, the values set in .zshrc seem to be ignored and and the default ‘xterm-256color’ is used (see my edit further up the post). I’ve noticed in nnn that when TERM is set to ’ xterm-256color’ and ‘]’ is pressed there are unwanted characters in the prompt.
What’s a “draw”?
If I open a terminal from a launcher (eg menu entry), then it works as expected as the terminal sources the .zshrc (or .bashrc). Are you using bash in these terminals? If so you need to set it in .bashrc.
A drawer is an item to store and organize apps. Right click on the panel > add to panel > drawer. Then Right cllck on the drawer to add items to it.
That would be a drawer, something I never use (I’d even forgotten about them).
I’ve just tested with a drawer, it’s working for me (as expected). So I assume you’re mixing shells and haven’t added it to .bashrc.
If you’re using a shell other than zsh or bash then you need figure out what file to put it in.
I’m using zsh with ‘export TERM=gnome-256color’ in .zshrc.
Try this:
Add to your drawer the ‘run command’, then open the run command and input ‘nnn -cdfgRUl1’. Then open a nnn terminal window ‘]’. Type ‘echo $TERM’. On my setup, I get ‘xterm-256color’, and unwanted characters after the prompt. It also fails when adding nnn as a custom application to the drawer, as described in the edit above. When mate-terminal is launched from the draw ‘echo $TERM’ returns ‘gnome-256color’.
Why? Alt + F2 for ‘run command’.
Why are you trying to open a CLI program without a CLI? It needs to be run in a shell that you have access to.
If I try this nothing happens, unsurprisingly, because it’s being opened (if it’s being opened) in the system shell, which we don’t have access to.
Just not sure why something opens up for you, but perhaps you’ve left out some details that explain it.
Again it needs a shell. What you want to do is open a terminal and then run nnn.
Put this in a launcher (the thing you add to the drawer):
mate-terminal -e nnn
Why do you insist on writing “draw” when you mean “drawer”?
You realise they’re different words?
It hel wh yo use wors properly, and describe what you’re doing.
Sorry for the typo, mate-terminal -e nnn fails.
Details.
You’re right, forgot to check it in the drawer. Give us a sec.
Same result, ‘xterm-256color’ is returned plus unwanted characters.
Sorry about the wait. This should work:
# ~/.local/bin/nnn_launcher
#!/usr/bin/bash
export TERM=gnome-256color
nnn
chmod +x ~/.local/bin/nnn_launcher
Then put this in the launcher:
mate-terminal -e /home/$USER/.local/bin/nnn_launcher
Replace $USER with your username.
The run command ‘nnn -cdfgRUl1’ worked because there is a tick box for running the command in a terminal.
Ah, so there is. I barely use “run command”, and never needed the tickbox.
EDIT:
I use guake, so I just press F12 and start typing.
I don’t get extra chars, just the value of TERM.
Was the value returned ‘xterm-256color’?
Just tried your suggestion of creating an executable file named nnn, but when it was launched from the drawer, I got an empty terminal, the CPU cores went to 80% and the system became unresponsive!
It was without the script (when launched from the drawer, or “run command”). The script works for me, including when launched from the drawer, I get gnome-256color.
Please paste the contents of the script so we can check it (I assume you copied it correctly, but 
). I take it you put it in ~/.local/bin?
I’m not at home and this laptop is kde, so I’m using another pc with mate for testing and it hasn’t been updated in a few weeks. I’m updating atm, to see if that will make a difference.
As expected, it still works fine even after a reboot.
It lives in ‘/home/manjaro/.local/bin’, my user name being manjaro.
owner:group is manjaro:manjaro
attributes are rwxr-xr-x
#!/usr/bin/bash
export TERM=gnome-256color
nnn
I’ve also tried #!/usr/bin/zsh, as I’m using zshell
That looks good. The shebang (#!/usr/bin/bash) has to be on the first line, is it? I think the script should work either way (it does here but this pc uses bash, I can test on zsh in a an hour or two).
What are the extra chars you get?
Just in case, what’s the command in the launcher?
Don’t use zsh for scripts, even if you use it as your shell. Bash is better for scripting and more portable than zsh.
The shebang line (#!) tells linux to run it using the proper shell.
Have you tried guake? It’s a drop down terminal, you can just press F12 (to drop down) and type nnn.
Shebang is at line 1, column 1. When using #!/usr/bin/bash, and launching from anywhere, I get repeated lines of “/usr/bin/bash: warning: shell level (1000) too high, resetting to 1” in the terminal. The installed nnn is in /usr/local/bin and the script is in ~/.local/bin. Could there be a conflict as to which has priority? The command in the launcher is ‘/usr/bin/mate-terminal -e /home/manjaro/.local/bin/nnn’. But just nnn in the mate-terminal also produces the CPU overload. The unwanted characters are ‘Enter’ to continue^[[I, so ^[[I has been added to the prompt.
Yeah I just got back and tested, and I got the same message, and then I realised where I went wrong:
~/.local/bin is in the PATH, and so when we call nnn it’s calling the script, which calls it again, and again, etc. 
It slipped my mind that the name would be a problem, and with it working on the other pc, apparently I needed something to remind me.
I’d rename it nnn_launcher or something like that. (I’ll fix the original post)
Sorry I wasn’t more careful with my choice of name. It was just for a quick test and it then got carried over.
I’m surprised no-one else picked up on it.
The reason it worked on the other computer, is that ~/.local/bin isn’t in the PATH variable.
Hopefully, one of the devs will read this and realize that the April 2023 updates have broken something in Manjaro’s inner workings!