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

[Max Nikulin <manikulin@gmail.com>]

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