emacs-orgmode
[Top][All Lists]
Advanced

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

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


From: Maxim Nikulin
Subject: bug#44824: 27.1; Org export as pdf and open file does not open it
Date: Sun, 31 Jan 2021 18:15:27 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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, tomas@tuxteam.de 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.





reply via email to

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