emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Bug in 9.5.3 org--file-default-apps


From: Max Nikulin
Subject: Re: [PATCH] Re: Bug in 9.5.3 org--file-default-apps
Date: Sun, 22 May 2022 14:40:25 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1

On 22/05/2022 11:10, Ihor Radchenko wrote:
Max Nikulin writes:

The source of the problem is that Emacs-27 was released with the
following bug:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247
mailcap-mime-data erased when parsing mime parts

So `mailcap-parse-mailcaps' called from `mailcap-mime-info' erases
predefined associations in Emacs-27.

If I understand correctly, this extra complication does not affect most
of the systems. I am not sure if we need to work around it.

I would say that view-mode is quite reasonable default to open a "text/plain" file and this bug broke it. I do not think that Craig really wants a new emacs session for every followed link:

    application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY"

Also, I am attaching a patch to address the original issue. We can just
use file command when available. WDYT?

Ihor, have you manged to reproduce the original issue? Are links with explicit .txt suffix [[file:file.txt]] affected by the same problem? My environments sometimes behave in a way unexpected to you and I have not setup any tool to quickly launch transient virtual machines with no fear to "broke" current state, so I have not tried to debug the reported issue in its original form.

I may be excessively suspicious.

diff --git a/lisp/org.el b/lisp/org.el
index d7da8efc4..3102fe611 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7975,7 +7975,12 @@ (defun org-open-file (path &optional in-emacs line 
search)
     (when (eq cmd 'mailcap)
       (require 'mailcap)
       (mailcap-parse-mailcaps)
-      (let* ((mime-type (mailcap-extension-to-mime (or ext "")))
+      (let* ((mime-type (if (executable-find "file")
+                            (shell-command-to-string
+                             (format "%s --brief --mime-type %s"
+                                     (executable-find "file")
+                                     file))

I hate elisp API related to executing of external processes because it encourages proliferation of unsafe code. What if the linked file name has some peculiarities and characters interpreted by shell?

   See [[file:/tmp/`touch /tmp/hacked`/test][here]]

I can not say that I fully understand `org-open-file' code, so I am unsure if remote file name can appear here, e.g. /ssh:user@host:testfie or a file form an archive due to a relative link [[file:testfile]] from a remote .org file. When remote files are not an issue, it is safer to use functions that takes command arguments as a list of string, not the command as a ready to execute string. Unfortunately there is no helper returning a string and accepting a command as a list.

+                          (mailcap-extension-to-mime (or ext ""))))
             (command (mailcap-mime-info mime-type)))
        (if (stringp command)
            (setq cmd command)

P.S. `org-open-file' already has some problems with handling of some file names:

Maxim Nikulin to emacs-orgmode. greedy substitution in org-open-file. Wed, 20 Jan 2021 23:08:35 +0700. https://list.orgmode.org/ru9ki4$t5e$1@ciao.gmane.io




reply via email to

[Prev in Thread] Current Thread [Next in Thread]