symlinked text files not honoring editor/visual

[mberlinger3]

Environment details (Put x in the checkbox along with the information)

[x] Operating System: Manjaro
[x] Desktop Environment: KDE
[x] Terminal Emulator: Konsole
[x] Shell: zsh
[ ] Custom desktop opener (if applicable):
[x] Program options used: -e
[ ] Configuration options set:
[x] Issue exists on nnn master

Steps to repro:
echo "Hello, World" >> file.txt
ln -s file.txt file2.txt
nnn -e and press enter over file2.txt@ >> file opened in kate (in my case)
nnn -e and press enter over file.txt >> file opened in cli editor

_Originally posted by @mberlinger3 in https://github.com/jarun/nnn/issues/885

[0xACE]

not sure which thread to talk in. but does your editor open symlinked files according to your expectations?

[mberlinger3]

I would assume that the -e flag would follow the symlink to the original file and try opening that with the cli editor instead of passing it to xdg-open. In the above example both files should be opened in the same way with the cli editor.

Edit: if I directly use micro (my editor) the symlink is opened as expected in the cli

[0xACE]

I'm not sure if my SEL_EDIT is the same as upstrema, but mine just spawn(editor0,... no symlink handling involved. and i tried vim symlinkobject and vim opened the target of the symblinkobject

Since im assuming SEL_EDIT doesnt account for symlinks in your machine either. There must be a difference in our enviornments. nnn should basically only $EDITOR symlinkedobject ... not sure what else to add without further debugging..

[mberlinger3]

I think I narrowed it down a bit further:

• txt file
  1. Presse: file opened in cli (nnn or nnn -e)
  2. Press enter: file is opened in cli (nnn -e)
  3. Pressenter: file is opened outside cli (nnn)
• Symlink file
  1. Presse: file is opened in cli (nnn or nnn -e)
  2. Press enter: file is opened outside cli (nnn -e)
  3. Pressenter: file is opened outside cli (nnn)

I think the issue is that the 2nd case does not match for both symlink and regular file at least on my system.

[jarun]

Please confirm if the patch works fine for you.

[jarun]

@sjmulder please confirm file option -L is avialble for the Sun platforms you support.

[mberlinger3]

Please confirm if the patch works fine for you.

Works perfectly!

[sjmulder]

-L is not available on Illumos (tested on OpenIndiana Hipster). The documentation says symlinks are followed by default:

       If _file_ appears to be a text file, file examines the first 512 bytes
       and tries to determine its programming language. If _file_ is a symbolic
       link, by default the link is followed and file tests the file to which
       the symbolic link refers.

The documentation for file on my Debian system says -L is implied if the POSIXLY_CORRECT is set:

     -L, --dereference
             option causes symlinks to be followed, as the like-named option
             in ls(1) (on systems that support symbolic links).  This is the
             default if the environment variable POSIXLY_CORRECT is defined.

Perhaps that's a slightly more portable option?

[jarun]

I don't see POSIXLY_CORRECT mentioned in openBSD man pages.

[sjmulder]

Yeah, OpenBSD doesn't seem to support it. NetBSD does. So on some platforms you get -L by default, on others -h, and some of those support POSIXLY_CORRECT to swap it back. Suppose it'll have to be tested for at compile time, or hardcoded with preprocessor platform checks.

[jarun]

Let's not make any changes till a user comes back with an issue. What's the point if no one is using the distro and/or nnn on it?

[jarun]

Also, I am pretty sure the people who are using these OS-es are capable of changing the code and compiling it for themselves.

[sjmulder]

Those people would be me fixing it in a pkgsrc patch, then I'd probably submit it as a PR. Might as well not pass -L if __sun is defined and be done with it.

[jarun]

Sure thing! :)