Open File Manager does not work in Konsole if MC is started

[maxim]

Let's bind 'Open File Manager' to Shift + Return.

1) Open KDE Konsole terminal.
2) Press Shift + Return
3) Terminal will open Dolphin
4) Start MC in the same terminal
5) Try again with Shift + Return
6) Command is failed with message 'The file or folder <host>/ does not exist.'

It looks like MC breaks something after start, <host> string probably uses FQDN of the host.

If I exit Midnight Commander issue is still present, so it breaks something in Konsole session and even do not restore that on exit. So only new Konsole terminal (for example new Tab) will work again.

---
GNU Midnight Commander 4.8.32
Built with GLib 2.82.2
Built with S-Lang 2.3.3 with terminfo database
Built with libssh2 1.11.1
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:

cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell

Data types:

char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

[zaytsev]

Let's bind 'Open File Manager' to Shift + Return.

Where do you bind this, what system is that?

If I exit Midnight Commander issue is still present, so it breaks something in Konsole session and even do not restore that on exit.

Did it work before with 4.8.31? If yes, then it may be related to #3088.

[maxim]

Where do you bind this, what system is that?

In Konsole app: Settings menu, Configure Keyboard Shortcuts, then type Open File Manager in Search input, choose corresponding item, set some key combination like Shift + Return.

Did it work before with 4.8.31? If yes, then it may be related to #3088.

Yes, it worked before, but I do not know when exactly it stopped to work (which version).

Any workaround to revert the previous behaviour and test it?

[zaytsev]

You can revert 6b44fce839b5c2e85fdfb8e1d4e5052c7f1c1c3a and check if it fixes the issue. If not, it's something else. Then you need to find a working version and bisect from there.

[maxim]

I reverted "Merge branch '3088_terminal_cwd'"

    This reverts commit 6b44fce839b5c2e85fdfb8e1d4e5052c7f1c1c3a, reversing
    changes made to dc1aa3e4e30f3f871a57a81cd7aa9156668b3db8.

It did not help, problem is still present.

[zaytsev]

Well, ok, then if you are confident, that it worked before, and the problem is with mc and not your DE, then you should find the earliest version that worked and git bisect from there to identify the commit that broke it.

[zaytsev]

diff --git a/src/filemanager/layout.c b/src/filemanager/layout.c
index ad27811f6..d9ee7f414 100644
--- a/src/filemanager/layout.c
+++ b/src/filemanager/layout.c
@@ -1589,14 +1589,12 @@ update_terminal_cwd (void)
 {
     if (mc_global.tty.xterm_flag && vfs_current_is_local ())
     {
-        const gchar *host;
         char *path, *path_uri;
 
-        host = g_get_host_name ();
         path = vfs_path_to_str_flags (current_panel->cwd_vpath, 0, VPF_NONE);
         path_uri = g_uri_escape_string (path, "/", FALSE);
 
-        fprintf (stdout, ESC_STR "]7;file://%s%s" ESC_STR "\\", host, path_uri);
+        fprintf (stdout, ESC_STR "]7;file://%s" ESC_STR "\\", path_uri);
         (void) fflush (stdout);
 
         g_free (path_uri);

[egmont]

There's no "official" documentation of OSC 7 that I'm aware of; to my best knowledge it originates from the default mac Terminal.app. I have no access to a mac to check the behavior there.

VTE has, for many years, set it to file://hostname/fullpath and it works there just fine. The advantage of filling out the host is that if you log in (e.g. ssh) to a remote host and change to a certain directory there, the terminal can know that it's not the same as the local directory of the same name. I'm pretty sure that VTE and mc aren't the only software doing this.

I'd argue that if Konsole or Dolphin fails to recognize a file:// URI with a non-empty hostname component then the bug is over there.

[egmont]

See also ​https://bugs.documentfoundation.org/show_bug.cgi?id=107461 - LibreOffice? used to fail to handle such URIs which caused a problem in terminals with OSC 8 hyperlinks. We managed to convince them and they fixed their software.

[egmont]

As per ​https://bugzilla.gnome.org/show_bug.cgi?id=779734#c120, the URI spec allows a hostname to be present even with the file scheme. And OSC 7 chose to use the URI syntax rather than, let's say, just inlining the directory name as-is.

This again suggests that passing the hostname should be fine, the culprit is the tool that fails to recognize it.

[zaytsev]

Thanks for the feedback! I was able to find the bug in Konsole and post an update there:

​https://bugs.kde.org/show_bug.cgi?id=483297

I hope that they can fix it, or maybe distro people can come up with a patch...

[egmont]

Thank you for finding the upstream bug and providing additional info there!

[zaytsev]

Funny, from Apple Terminal settings (!), see screenshot:

The working directory and location of the current document may be set using the Operating System Command (OSC) escape sequence:

ESC ] Ps ; Pt BEL

The parameter Ps is either 6 (document) or 7 (working directory) and Pt is a “file:” URL. The URL should include a hostname to disambiguate local and remote paths, and characters must be percent-encoded as appropriate.

When both the working directory and document are set only the document is displayed.

I guess this is as official as it can get.

[zaytsev]

I'm going to close this for now as it's not a bug in mc.