emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <m.a.nikulin@gmail.com>
To: 44824@debbugs.gnu.org
Cc: Eli Zaretskii <eliz@gnu.org>, gbiotti@gmail.com
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	[thread overview]
Message-ID: <e9154a33-e8c1-094e-7562-adbdc2b34593@gmail.com> (raw)
In-Reply-To: <83lfca8k4e.fsf@gnu.org>

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: 

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 

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	other threads:[~2021-01-31 11:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFbX=UpDN9XtTr3osTC6B=V0trvatayw5WF0gMjGWAWfQQkAXg@mail.gmail.com>
     [not found] ` <f395c79a-c3e3-52c7-3fbb-608e94868e8e@gmail.com>
2021-01-27  3:36   ` Lars Ingebrigtsen
2021-01-27  8:33     ` gbiotti
2021-01-28  3:02       ` Lars Ingebrigtsen
2021-01-28 11:20         ` gbiotti
2021-01-28 11:31         ` gbiotti
2021-01-29  4:51           ` Lars Ingebrigtsen
2021-01-29  6:59             ` Geraldo Biotti
2021-01-30  6:09               ` Lars Ingebrigtsen
2021-01-30  7:50                 ` Geraldo Biotti
2021-01-30  8:42                 ` Eli Zaretskii
2021-01-30 13:31                   ` Maxim Nikulin
2021-01-30 13:49                     ` Eli Zaretskii
2021-01-30 15:58                       ` Maxim Nikulin
2021-01-30 16:28                         ` Eli Zaretskii
2021-01-31 11:15                           ` Maxim Nikulin [this message]
2021-01-31 11:37                             ` tomas
2021-01-31 15:05                             ` Eli Zaretskii
2021-01-31 15:17                               ` Andreas Schwab
2021-01-31 15:34                                 ` Eli Zaretskii
2021-01-31 15:21                               ` Lars Ingebrigtsen
2021-01-31 15:57                               ` Maxim Nikulin
2021-01-31 16:33                                 ` Eli Zaretskii
2021-01-31 17:07                                   ` Maxim Nikulin
     [not found]                                 ` <83o8h56p7o.fsf__8661.17158891342$1612110869$gmane$org@gnu.org>
2021-02-18 12:56                                   ` [PATCH] org.el: Avoid xdg-open silent failure Maxim Nikulin
2021-02-18 14:48                                     ` bug#44824: " Eli Zaretskii
     [not found]                                     ` <83a6s15t51.fsf__31631.6350990505$1613659778$gmane$org@gnu.org>
2021-02-19 12:29                                       ` Maxim Nikulin
2021-02-19 14:54                                         ` Eli Zaretskii
2021-02-19 16:45                                           ` Maxim Nikulin
2021-03-19  3:50                                     ` Kyle Meyer
2021-03-20 15:45                                       ` Maxim Nikulin
2021-03-21 15:01                                         ` Kyle Meyer
2021-01-30 16:39                     ` bug#44824: 27.1; Org export as pdf and open file does not open it gbiotti
2021-01-30 18:50                       ` Bhavin Gandhi
2021-01-31  7:17                   ` Lars Ingebrigtsen
2021-01-31  7:39                     ` Tim Cross
2021-01-31  9:09                       ` tomas
     [not found]         ` <108399a5-66ad-eee6-572b-b3f2181e4e6c__47986.5006914892$1611843550$gmane$org@gmail.com>
2021-01-28 16:10           ` Maxim Nikulin
     [not found]   ` <87y2gfcape.fsf_-___1545.58022493205$1611718675$gmane$org@gnus.org>
2021-01-27 12:14     ` Maxim Nikulin
2021-01-27 13:33       ` Maxim Nikulin
     [not found]     ` <0f4437bc-3e40-fe47-d6e7-d33c2fb7965a__46427.8968678386$1611759102$gmane$org@gmail.com>
2021-01-27 16:21       ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9154a33-e8c1-094e-7562-adbdc2b34593@gmail.com \
    --to=m.a.nikulin@gmail.com \
    --cc=44824@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=gbiotti@gmail.com \
    --subject='Re: bug#44824: 27.1; Org export as pdf and open file does not open it' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).