nnn blocks CLI when opening a file in a TTY with xdg-open

[DinoPetrucci]

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

[x] Operating System: Debian 10
[ ] Desktop Environment:
[ ] Terminal Emulator:
[x] Shell: Dash
[ ] Custom desktop opener (if applicable):
[x] Issue exists on nnn master

Exact steps to reproduce the issue

When I try to open a file using Enter (or l or the right key) in a TTY, nnn 2.6 doesn't work well: the file is not open, no message is output, and the keyboard seems to be blocked (I hardly escape from nnn and the CLI). I have default settings and xdg-open as "opener" (which works fine in TTY on the same files outside nnn). Replacing the line

spawn(opener, newpath, NULL, NULL, F_NOTRACE | F_NOWAIT);

with

spawn(opener, newpath, NULL, NULL, F_CLI);

when nnn "Invoke desktop opener as last resort" in the source code, everything works in TTY (but the result is awful in the GUI).

[jarun]

What type of files are you trying to open?

Also, try the workaround from @0xACE in #319.

[jarun]

Also, did you do:

export NNN_USE_EDITOR=1

[DinoPetrucci]

What type of files are you trying to open?

HTML (as they should appear in links, not their source code) or even bitmapped images using cacaview.

Also, try the workaround from @0xACE in #319.

I tried it for xdg-open but nothing happens within nnn and everything was messed up in the TTY: I had to kill the process from another terminal, and the cursor disappears from the TTY despite being exited (I had to reboot)!

Also, did you do:

export NNN_USE_EDITOR=1

I did but, as I wrote before, I don't want to see the source code of an HTML; however the problem remains for non-text files (like bitmapped images).

[jarun]

I did but, as I wrote before, I don't want to see the source code of an HTML; however the problem remains for non-text files (like bitmapped images).

For me xdg-open is a script.

I am using Xubuntu and here's my /usr/bin/xdg-open: http://paste.ubuntu.com/p/gms97JHRSB/

My case should be handled in open_xfce() and it works just fine.

Can you check the difference with yours? It seems xdg-open detects the DE and uses DE specific tools to open files. Please check what's happening for your DE.

[jarun]

Continuing my answer, what happens if you use:

spawn(opener, newpath, NULL, NULL, F_NOTRACE);

Do the files open correctly in GUI application? nnn may block but I want to understand if the files open correctly.

[jarun]

Also, can you try:

export NNN_OPENER=mimeopen

and open those files in nnn?

[DinoPetrucci]

[...] My case should be handled in open_xfce() and it works just fine.

Can you check the difference with yours? It seems xdg-open detects the DE and uses DE specific tools to open files. Please check what's happening for your DE.

My problem is not nnn in a DE, but in a TTY. When I execute xdg-open (in a TTY, outside nnn) for an image (e.g. /home/dfp/bouton.jpg) these are the processes:

/bin/sh /usr/bin/xdg-open bouton.jpg
/usr/bin/perl /usr/bin/run-mailcap --action=view bouton.jpg
sh -c unset DISPLAY; /usr/bin/cacaview '/home/dfp/bouton.jpg'
/usr/bin/cacaview /home/dfp/bouton.jpg

That is: xdg-open goes into the function open_generic(), since I am not in a DE.

Inside nnn (always in a TTY) I get:

nnn
/bin/sh /usr/bin/xdg-open /home/dfp/bouton.jpg
www-browser /home/dfp/bouton.jpg

That is: xdg-open goes into open_generic() but cannot run rum-mailcap (because of the flag F_NOTRACE, I suppose) so it runs www-browser at the end of the function (I didn't set $BROWSER) which corresponds, in my system, to links. Indeed, outside nnn, the
command

$ www-browser /home/dfp/bouton.jpg

simply opens links; inside nnn, nothing happens but the keyboard malfunction, and the process remains even if I get out of nnn (because of the flag F_NOWAIT).

[...] what happens if you use:

spawn(opener, newpath, NULL, NULL, F_NOTRACE);

Do the files open correctly in GUI application? nnn may block but I want to understand if the files open correctly.

Yes the files open correctly in the GUI, but not in the TTY. Only the combination of flags F_CLI works fine in a TTY (I've already tested other combinations).

Also, can you try:

export NNN_OPENER=mimeopen

and open those files in nnn?

Using mimeopen, nnn opens the files in the GUI correctly; while in a TTY nothing happens as if no "opener" is called (no process remains in memory and the CLI works). But this is not what I expect.

[jarun]

My problem is not nnn in a DE, but in a TTY.

OK. This wasn't clear to me earlier.

So all your utilities will be opened in CLI by opener. Is that correct?

If that's the case the following statement does not make any sense:

(but the result is awful in the GUI)

Let's make it clear that you can't have your opener mix GUI and CLI utilities for different mimes.

Now, if you can confirm all your preferred apps are (and will be) CLI based, we can definitely throw in a program switch to handle this.

[jarun]

Please test the patch and confirm.

[DinoPetrucci]

The patch works!

I clarify that I use nnn in both TTY (Linux console) and GUI (terminal emulator), so I need it to work fine in both cases. With your patch I can instruct the CLI like this:

if [ $XDG_SESSION_TYPE = "tty" ]; then
  alias nnn="nnn -cd"
else
  alias nnn="nnn -d"
fi

Now I can run nnn without problems (about the "opener"). Thank you very much.

[jarun]

Ahh, $XDG_SESSION_TYPE makes sense!

Now I can make all of it automatic for you. No need for the additional program option!

Give me 5 mins.

[jarun]

Try the latest patch and confirm. You wouldn't need to use the option -c.

[DinoPetrucci]

Ahh, $XDG_SESSION_TYPE makes sense!

Now I can make all of it automatic for you. No need for the additional program option!

Give me 5 mins.

Sorry, but I don't think it's a good idea. The user should be able to use an option if the things go wrong. Furthermore the environment variable XDG_SESSION_TYPE is set on my system or in GNU/Linux. But... in another OS like Mac OS X? And if a system configuration use a different value? In any case there are cleaner solutions (see https://stackoverflow.com/questions/13204177/how-to-find-out-if-running-from-terminal-or-gui). I suggest you to keep the -c option. Other checks should be valuated carefully.

[jarun]

in another OS like Mac OS X?

macOS doesn't have virtual terminals or X so the check would fail anyway.

However, I think we can have a middle ground. We keep the option and on Linux we also check for $DISPLAY. If $DISPLAY is NULL, we can use the flag F_CLI. What do you think?

[jarun]

Check out the latest patch and let me know your opinion.

[DinoPetrucci]

However, I think we can have a middle ground. We keep the option and on Linux we also check for $DISPLAY. If $DISPLAY is NULL, we can use the flag F_CLI. What do you think?

"An hour in the morning is worth two in the evening."

$DISPLAY is not a POSIX environment variable and it is set by X11. What about Wayland? I've never tried pure GNOME-Wayland: does it use $DISPLAY or $WAYLAND_DISPLAY or what else?

Also the isatty() solution is an invalid one for our case: it just checks if the stdin is connected to a CLI directly or a pipe/file. The first case is true either in a TTY console or in a GUI terminal emulator.

I thought about $TERM, but it's too complicated, in spite of the conventions (see man 7 term).

My last recommendation is: keep the -c option only, without any automatic check/set. This provides a default behaviour for GUI terminal emultors and, if a user works inside the console, he/she can easly force the F_CLI combination of flags if he/she really needs to.

I think you should revert to "Fix #334: Detect session type" again: it's cleaner and safer.

[jarun]

That makes sense. I will revert to the original fix and leave it to users to control the behaviour.

[jarun]

OK. I dug a little more and it looks your guess was correct: https://fedoraproject.org/wiki/How_to_debug_Wayland_problems

So wayland sets WAYLAND_DISPLAY. I think X11 and Wayland are the only major display servers in vogue today. So why not extend the current check and confirm that neither DISPLAY nor WAYLAND_DISPLAY are set and then fallback to F_CLI on Linux?

[DinoPetrucci]

[...] So wayland sets WAYLAND_DISPLAY. I think X11 and Wayland are the only major display servers in vogue today. So why not extend the current check and confirm that neither DISPLAY nor WAYLAND_DISPLAY are set and then fallback to F_CLI on Linux?

I think that, in this case, relying on the environment variables is a weak and a dangerous choice. Forget it and keep the -c option only: it's enough. Final recommendation: revert to the original fix and leave to the users the control.

[jarun]

Done! I'll revert to the original fix.

[jarun]

@DinoPetrucci and @0xACE I think what we were looking for here is:

ttyname(STDIN_FILENO)

Output at xfce4-terminal:

/dev/pts/0

Output at virtual terminal 1:

/dev/tty1

What do you guys think?

[KlzXS]

That is a reliable way of differentiating a virtual terminal from a graphical terminal emulator. Just keep in mind that when connecting over ssh (even when using it directly from a tty) it will return /dev/pts/x.

[jarun]

@KlzXS I am retaining the -c option. However, I would very much like to auto-detect a local tty and deliver the best experience to users automatically.

[jarun]

Also, this is POSIX compliant and looks like both macOS and BSD support it.

However, I am not sure of the nomenclature followed in macOS and BSD for tty and pts. So, right now I can only make this change for Linux.

[jarun]

Sample patch:

```

```diff --git a/src/nnn.c b/src/nnn.c
index 85004e1..6e78501 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -3369,6 +3369,15 @@ static void browse(char *ipath)

    atexit(dentfree);

+#ifdef __linux__

• /* Detect tty */
• if (!cfg.cliopener) {
• tmp = ttyname(STDIN_FILENO);
• if (tmp && (strstr(tmp, "/dev/tty") == tmp))
• opener_flags = F_CLI;
• }
  +#endif
  +
  /* setup first context /
  xstrlcpy(g_ctx[0].c_path, ipath, PATH_MAX); / current directory */
  path = g_ctx[0].c_path;

[KlzXS]

That should work, but a quick look around the internet concluded that the concept exists since the days of Unix but that the naming convention of master and slave pseudo terminals can differ. For example man pts says the following

The Linux support for the above (known as UNIX 98 pseudoterminal naming) is done using the devpts filesystem, that should be mounted on /dev/pts.
Before this UNIX 98 scheme, master pseudoterminals were called /dev/ptyp0, ...  and slave pseudoterminals /dev/ttyp0, ...  and one needed lots of preallocated device nodes.

So a better check might be needed if some systems still use such naming conventions.

[jarun]

Yes, I am dropping the idea. It varies from OS to OS. We'll keep it explicit with -c.