nnn’s bulk rename no longer works after April 2023 updates when running on mate-terminal. The bulk rename works with other terminal emulators and oddly with mate-terminal running a tmux session. When selecting files in nnn and then pressing ‘r’, there should be a current/select prompt, but ‘failed’ is returned. The nnn developers tell me that this is a local problem and not a nnn bug.
Manjaro is a rolling release. You can’t lag 6 months behind the current updates and expect stuff to work.
Edit: sorry, i misunderstood.
1 Like
April 2023 was when the fault first presented, not the current state of the system which is fully up to date.
They said it was a local environment problem.
So did you try diffing env output in mate-terminal vs another where it works?
Not sure what they ment by diffing the environment. This problem occurrs on mutiple machines and is clearly due to the April 2023 updates. Has anyone tried to reproduce this problem on their machines?
Just to be clear, I compiled vanilla nnn v4.9 with regex support. ie, make O_PCRE=1 strip, sudo make install. This required libpcre3-dev to be installed.
In mate-terminal do env > env1.txt then in another terminal where it works do env > env2.txt. Then diff env1.txt env2.txt and see what is different.
Why aren’t you using nnn from Manjaro packages?
It wasn’t clear that they were compiled with regex support.
Edit: To be more precise, perl compatible regular expression (PCRE) support.
I have redirected the 'env’output from three terminals, xterm, alacritty and mate-terminal. Also, mate-terminal running a tmux session. xterm, alacritty and the tmux session all work with nnn. Diffing with meld or gvimdiff didn’t yield any useful information, as there were too many differences to make out where the problem lies. Also, each file runs to approximately one hundred lines, which would take up a lot of space pasting them on to the forum.
Edit: I’ve put all the files through sort, which made them more easy to diff. However, only someone with more programming experiance could determine the cause of the problem.
Ok, but what you’ve done (installing software via sudo make install) is not supported and not recommended. There are no guarantees about it working or breaking or anything else, and if you don’t have the knowledge required to fix it when it does break then you probably shouldn’t be installing software like that. Sorry, but that’s how it is.
1 Like
This issue has nothing to do with how nnn is installed. It fails when installed from the manjaro repository and it fails if it is compiled from source. It was working perfectley before the April 2023 updates and it is perfectly clear where the fault lies. If you are not convinced, install it from the official repository and watch it fail for yourself.
I installed it, ran it in mate-terminal and successfully batch renamed 2 files…
EDIT:
I figured out how to select files…and it fails in both mate-terminal and guake. Works if you don’t select files though (seems odd).
Regexes work so you shouldn’t need to build it yourself.
EDIT2:
It works properly in a TTY, which reminded me to look at the env.
# these work
TERM=linux
TERM=screen
TERM=screen-256color
TERM=tmux-256color
TERM=gnome-256color
# these don't
TERM=xterm-256color
TERM=xterm
# to test
TERM=screen nnn
I’ve noticed that screen-256color breaks Home and End, but gnome-256color doesn’t.
To make it permanent put this in your .bashrc or .zshrc
export TERM=gnome-256color
For a list of other possible values, use toe and/or a search engine.
I uninstalled the version (4.9) that was compiled with PCRE support and installed the current version from the repository, ran ‘nnn -cdfgRUl1’ and it failed the -ve lookahead test. Press / followed by ^(?!bar) and all instances of names begining with ‘bar’ should be removed from the listing.
I have some screen shots of a diiff of env for xterm (works) and mate-terminal (fails) - both files were sorted before diffing using meld but when I tried to upload them, there was an error regarding imbedding them in the post.
I have this in my .zshrc:
if [ $TERM==‘xterm’ ]; then
export TERM=‘xterm-256color’
fi
This entry pre-dates April 2023 when there wasn’t a problem.
You only said regex support, and basic regexes do work eg ^[0-9]. If you’d given an example I would’ve tested it.
Are you trying to say that it’s not the cause, or that it could be the cause?
What happened to the testing? Have you tried TERM=screen-256color nnn yet?
Yes I have run some tests. I removed all entries relating to setting the TERM variable from .zshrc. I then rebooted and ran ‘echo $TERM’ from mate-terminal, which returned ‘xterm-256color’. So if not specified, TERM defaults to ‘xterm-256color’. I then ran tmux in mate-terminal and ‘echo $TERM’ returned ‘tmux-256color’. nnn running in a tmux session worked because TERM was not set to ‘xterm-256color’. So a workaround is to set TERM to ‘screen-256color’ in .zshrc.
Edit: Just tried to run nnn from a panel drawer with a custom application launcher.
Command: mate-terminal --name=‘nnn file manager’ --profile=nnn --command ‘nnn -cdfgRUl1’
Pressing ‘]’ in nnn and running ‘echo $TERM’ returns ‘xterm-256color’. So it has dropped back to the default and fails.
I’ve noticed screen-256color breaks my Home and End keys, gnome-256color doesn’t.
Was this a global failure of HOME/END or just within nnn?
Within a terminal when the .zshrc is sourced. It doesn’t happen when I set the TERM manually.
Sadly, tinkering with the TERM environment variable is only a partial solution and I wonder if any other programs have been effected.
EDIT: I’ve had another look at Alacritty. Whenever it’s launched (menu, panel or drawer), it sets TERM to ‘alacritty’, TERM not being set in .zshrc, thus avoiding the ‘xterm-256color’ problem.