External panelize: opening a file with an absolute path fails

[ackalker]

What version of Midnight Commander is used?

$ LC_MESSAGES=C mc -V
GNU Midnight Commander 4.8.6
Built with GLib 2.32.4
Using the S-Lang library with terminfo database
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
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

What steps will reproduce the problem?

1. Create a test HTML file (content doesn't matter):

$ touch /tmp/t.html

2. In Midnight Commander, select Command -> External Panelize

3. as Other Command / Command, enter:

echo /tmp/t.html

4. In the panelized listing, select the file /tmp/t.html and press Enter to open it.

What is the expected output?

The HTML file should open in my webbrowser

What do you see instead?

(using PCManFM) an Error popup saying "No such file or directory".

After editing the extension file to change the html / open action, I found that Midnight Commander is trying to open the file ${HOME}/tmp/t.html instead of /tmp/html.
Note. Viewing and editing files with absolute paths in External panelize works without problems.

[ackalker]

I.e.: the variable MC_EXT_FILENAME appears to be set to ${HOME}/tmp/t.html instead of /tmp/t.html

[and]

Confirmed, absolute paths result not respected by External panelize.

Patch attached.

[zaytsev]

:-(

[mooffie]

Summary

When "External panelize" or "File find" think the result (the file list) has absolute paths, they set the panel's cwd_vpath property to "/" (and chdir() to there). This makes everything work (like patterns of the form "%d/%p" (there will be a double "/" at the beginning but that's harmless on POSIX systems), and ctrl+shift+enter for putting an absolute path on the command-line).

The bug's immediate cause

For "External panelized", there's a bug in how do_external_panelize() detects absolute paths: it looks in the zero'th element (the "..") instead of the 1'st one.

The bug's real cause

MC has several panelization-related bugs (I'll open tickets for individual bugs as time goes by). They all have one cause: lack of source-code documentation. This leads, as MC evolves and its code changes, to bugs because the intentions of the original programmer are lost.

As for @and's patch

@and's patch doesn't fix the "real cause". Also, as my branch shows, there are seveal more fixes to be done. I went to the lengths of giving him credit in the 1st commit, though. (His optimization for the "\n" trimming will be handled in #3811 instead; "#define LABELS" in #3780.)

[mooffie]

branch: 2942_panelize_absolutize
Initial changeset:c9f058e65bc18ee1e6b1874733863df4746d075f

[mooffie]

Merged to master: [e0cd82a10128df5593d6a4592034979c6f5bc2c7]

[mooffie]

NEWS-4.8.20 updated.