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

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).

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 27 (19 by maintainers)

Commits related to this issue

Fix #334: Detect session type — committed to jarun/nnn by jarun 5 years ago
Revert "Fix #334: Detect session type" This reverts commit e226e8c889e1a218f7ad2ecd669bc6ad00ccca22. — committed to jarun/nnn by jarun 5 years ago

Most upvoted comments

Done! I’ll revert to the original fix.

jarun on Oct 3, 2019

[…] 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.

DinoPetrucci on Oct 3, 2019

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.

DinoPetrucci on Oct 3, 2019

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.

DinoPetrucci on Oct 2, 2019

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 on Oct 2, 2019