[Top][All Lists]

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

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

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


Your patch may be an improvement, but it requires an additional fix, see below.

However, in my opinion, it does not address original Craig's issue. The patch improves handling of *non-text* files requiring *external* viewers, while Craig complained that behavior for shell script is incorrect and his problem is tightly bound to erased `mailcap-mime-data'.

I can not reproduce behavior he observed exactly, Org does not opens shell scripts by less, but it tries and silently (it is expected) fails.

My results (emacs-27):
1. If there is no mailcap files at all, the script is opened
   in the same emacs session that is correct from my point of view.
2. If I add ~/.mailcap
       text/plain; less '%s'; needsterminal
   then I get silent failures
       Running less /etc/profile...done
3. With your patch and the following additional entry in ~/.mailcap
   (notice "text" instead of "application" and just "emacs")
       text/x-shellscript; emacs %s; test=test -n "$DISPLAY"
   new Emacs session is started. It is a problem but partially
   it is caused by incorrect mailcap configuration.
   Unlike "text/plain" that would be handled by view-mode
   unless `mailcap-mime-data' were erased in Emacs-27,
   "text/x-shellscript" is handled by less on my main system
   due to mailcap while I would expect same Emacs session.

I read implementation of `org-open-file' once more and now I see that currently remote files can not be processed by mailcap code path even with custom `org-file-apps', so thank you for explanation. In some cases it may be handy to launch remote viewer from a host accessed through ssh, but let's leave it aside.

-      (let* ((mime-type (mailcap-extension-to-mime (or ext "")))
+      (let* ((mime-type (if (executable-find "file")

I would consider (and ... (not remp)) despite currently it is redundant. Just to mitigate consequences if other parts of this complicated function will be modified. On the other hand `start-process-shell-command' is not ready for remote files anyway, so major cleanup would be required.

+                            (shell-command-to-string
+                             (format "%s --brief --mime-type %s"
+                                     (executable-find "file")
+                                     (shell-quote-argument 
(convert-standard-filename file))))

It is not enough to cure my paranoia. However the following case is rather pathological

mkdir 'Program Files'
ln -s /usr/bin/file 'Program Files'/
PATH="$HOME/Program Files:$PATH" \
   emacs -Q -L ~/src/org-mode/lisp/ ~/examples/org/open-script.org &

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("/" nil 0)
  split-string(nil "/")
mailcap-mime-info("/bin/bash: line 1: /home/ubuntu/Program: No such f...") (let* ((mime-type (if (executable-find "file") (shell-command-to-string (format "%s --brief --mime-type %s" (executable-find "file") (shell-quote-argument (convert-standard-filename file)))) (mailcap-extension-to-mime (or ext "")))) (command (mailcap-mime-info mime-type))) (if (stringp command) (setq cmd command) (setq cmd 'emacs)))

+                          (mailcap-extension-to-mime (or ext ""))))

Agree. Though it is not directly related. Maybe you can bump that thread
and mark is as a bug report to be listed on

It is already tracked there as
"org-open-file & org-file-apps multiple substitution bug"
but my point was that great care is required otherwise a lot of issues may happen with shell command.

Ihor Radchenko. Bug in 9.5.3 org--file-default-apps.
Wed, 25 May 2022 14:18:10 +0800.

'>$ run-mailcap myscript'

One comment. I do not personally have run-mailcap command on my system,
but searching for its docstring reveals

 If the mime-type is omitted, an attempt to determine the type is
 made by trying to match the file’s extension with those in the
 mime.types files.

So, run-mailcap itself does not look inside the file and only checks the
extension. AFAIU. Correct me if I am wrong.

It is a Debian extension. Local man page has the following statement (confirmed by code and strace):

If no  mime-type is found, a last attempt will be done by running the
file command, if available.

reply via email to

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