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

[Max Nikulin]

Ihor,

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
> https://updates.orgmode.org/?

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.
https://list.orgmode.org/8735gy2l0d.fsf@localhost

> > '>$ run-mailcap myscript'
>
> One comment. I do not personally have run-mailcap command on my system,
> but searching for its docstring reveals
> (http://www.linux-commands-examples.com/run-mailcap):
>
> > >  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.