Subject: Re: bug#44824: 27.1; Org export as pdf and open file does not open it

From: Maxim Nikulin <[email-masked]>
Date: Sun, 31 Jan 2021 18:15:27 +0700

Bhavin, thank you very much for your clear report. I have tried once 
more with eshell session and this time I was lucky enough to reproduce 
the problem in both gnome and kde sessions on Ubuntu-20.04 focal

On 30/01/2021 23:28, Eli Zaretskii wrote:
>> From: Maxim Nikulin
>> Date: Sat, 30 Jan 2021 22:58:06 +0700
>>
>> The problem is that emacs does not expect that kde-open5 and thus
>> xdg-open exits instantly.
> 
> Why is that a problem, and how does it cause the invocation to fail,
> i.e. not show the file in question?
> 
>> The question could be addressed to KDE developers, but unlike the
>> issue with temporary files, in my opinion, pty+SIGHUP problem should
>> be fixed in org mode.
> 
> What do you mean by "pty+SIGHUP problem" in this case?  What exactly
> is the problem?

In the https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824#22 message I 
have posted a link to another thread in emacs-orgmode mail list thread 
with my earlier strace results: 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00327.html

Now I see that the problem with eshell is the same. I am not familiar 
with eshell, but it creates new shell process for every executed 
command. Actual handler is killed when underlying handler (kde-open5, 
"gio open") and thus xdg-open and the main shell process exit.

Excerpts from strace obtained for a eshell buffer

2221  16:59:43.513366 execve("/bin/sh", ["/bin/sh", "/usr/bin/xdg-open", 
"/tmp/test.pdf"], 0x7fff74be7f10 /* 58 vars */ <unfinished ...>
2224  16:59:43.566865 execve("/usr/bin/gio", ["gio", "open", 
"/tmp/test.pdf"], 0x55ee8454ec18 /* 58 vars */) = 0
2229  16:59:43.711846 execve("/bin/sh", ["/bin/sh", "-e", "-u", "-c", 
"export GIO_LAUNCHED_DESKTOP_FILE_PID=$$; exec \"$@\"", "sh", "evince", 
"/tmp/test.pdf"], 0x55bb59e67bb0 /* 59 vars */ <unfinished ...>
2221  16:59:43.717489 +++ exited with 0 +++
2229  16:59:43.719228 +++ killed by SIGHUP +++

Functions dealing with asynchronous processes in emacs, namely 
(start-process ...) and its siblings for shell commands calls 
(make-process :connection-type 'pty ...) that creates a pseudoterminal. 
It is redundant for applications that do not require an interactive 
terminal. When process (xdg-open this case) exits, pty is closed, all 
processes from the same terminal group receives SIGHUP. So actual 
handler is killed unless it has set signal handler or has detached from 
terminal session.

To fix the problem it is better to use (make-process :connection-type 
'pipe ...) that unfortunately has no higher level wrappers. "Pipe" 
process does not creates a pseudoterminal thus its children do not get 
SIGHUP on the exit of the main process. I am unsure concerning best 
values for other arguments however. The complication is that some 
mailcap entries have needsterminal flag, on the other hand they are 
likely irrelevant for GUI.

There is no problem if okular or evince are called directly (without 
kde-open5 or "gio open" wrapper) since main process does not exit while 
window is open.

Maybe the following command executed in eshell (namely eshell, not just 
shell) buffer is the best to demonstrate the problem (for those whose 
desktop environment is affected)

     sh -c "xdg-open /tmp/test.pdf; sleep 5"

The window with file content appears for 5 seconds then the viewer is 
killed.

On 31/01/2021 16:09, [email-masked] wrote:
> This chaotic behaviour gives me the impression that it's an
> environment thing: desktop environments have the tendency to prime
> the environment variables in "creative" ways, often different from
> what a login shell would do.

Certainly the behavior depends on the desktop environment. You could 
check which DE-specific handler is called (and factor-out xdg-open) with

     sh -x /usr/bin/xdg-open /tmp/test.pdf

As to other options, M-! executes the process synchronously and is not 
affected. M-& has the same pty+SIGHUP problem.

I am almost sure that I have tried eshell before, but I have no idea why 
I have not noticed the problem that time.