Re: [BUG] [C-u C-u C-c C-o] open link with external program invalid to open file

[Maxim Nikulin <manikulin@gmail.com>]

On 05/09/2020 14:52, Bastien wrote:
> 
> stardiviner <numbchild@gmail.com> writes:
> 
>> When I press =[C-u C-u C-c C-o]= to open an image file link with system external
>> program. It can't open the image file.
> 
> I cannot reproduce the problem here.
> 
> If you still have this issue, can you provide a minimal reproducible
> example?

Christopher Miles recently posted a link to askubuntu that shed some 
light on the problem.

I have compared the following commands:

(start-process-shell-command "xdg-open" nil "xdg-open 
/usr/share/icons/gnome/256x256/actions/stock_print.png")
(start-process-shell-command "eog" nil "eog 
/usr/share/icons/gnome/256x256/actions/stock_print.png")

The latter works in my (test) case (Ubuntu-20.04, ubuntu session - 
gnome), the former does not. If I do not mistake, 
start-process-shell-command is what org mode uses to open file.

Meaningful lines from strace of the emacs process

24108 21:39:51 execve("/bin/bash", ["/bin/bash", "-c", "xdg-open 
/usr/share/icons/gnome/"...], 0x7ffcb1c1fdb0 /* 55 vars */ <unfinished...>
24116 21:39:51 execve("/usr/bin/eog", ["eog", 
"/usr/share/icons/gnome/256x256/a"...], 0x55d009672ec8 /* 57 vars */ 
<unfinished ...>
24108 21:39:51 +++ exited with 0 +++
24116 21:39:51 +++ killed by SIGHUP +++

I think, the problem is that start-process-shell-command creates a "pty" 
process. As soon as main command exits, all children, that belong to the 
same terminal session created by emacs for the process, got killed.

Calling eog directly works because of it does not attempt to go to 
background or demonize.

The solution could be (make-process :connection-type 'pipe ...). 
Personally I would prefer to avoid shell as well when it is not really 
necessary.

I am surprised that in the discussion of problem related to desktop 
integration and perhaps even order in which applications able to handle 
particular file format were installed, nobody mentioned such details, 
neither for "positive" nor for "negative" results. Probably output of 
the following commands (for the proper mime type) could be relevant. The 
complication is that there are several mime handler "databases".

grep image/png /etc/mailcap ~/.mailcap
xdg-mime query default image/png

(mailcap-parse-mailcaps)
(mailcap-mime-info "image/png")

For some handlers there might be even a race, sometimes it might work 
but might fail as well, depending if child could send a message to its 
server quickly enough. In such case providing of ECM might be a challenge.