From: Maxim Nikulin <m.a.nikulin@gmail.com> To: 44824@debbugs.gnu.org Cc: 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: 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.
WARNING: multiple messages have this Message-ID (diff)
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: 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.
next prev parent reply other threads:[~2021-01-31 11:15 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-23 17:40 bug#44824: 27.1; Org export as pdf and open file does not open it Geraldo Biotti 2020-11-23 18:37 ` bug#44824: More info gbiotti 2021-01-27 3:36 ` bug#44824: 27.1; Org export as pdf and open file does not open it 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 8:42 ` Eli Zaretskii 2021-01-30 13:31 ` Maxim Nikulin 2021-01-30 13:49 ` Eli Zaretskii 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:15 ` Maxim Nikulin 2021-01-31 11:37 ` tomas 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 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 12:29 ` Maxim Nikulin 2021-02-19 14:54 ` Eli Zaretskii 2021-02-19 14:54 ` Eli Zaretskii 2021-02-19 16:45 ` Maxim Nikulin 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-03-21 15:01 ` Kyle Meyer 2021-03-20 15:45 ` Maxim Nikulin 2021-03-19 3:50 ` Kyle Meyer 2021-02-18 12:56 ` Maxim Nikulin 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 2021-01-28 3:02 ` Lars Ingebrigtsen [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 2021-01-27 12:14 ` Maxim Nikulin 2021-01-27 16:21 ` Glenn Morris 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * 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=gbiotti@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.