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

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com

Create a new org file and save it.
Try to export to LaTeX as PDF file and open (C-c C-e l o)

This is what *messages* says:
(New file)
Saving file /tmp/test2.tex...
Wrote /tmp/test2.tex
Processing LaTeX file test2.tex...
PDF file produced.
Running /usr/bin/xdg-open /tmp/test2.pdf...done

The default PDF program (okular) appears to open (i see the icon, but not
the window) and closes without showing anything.

Working on Manjaro Linux 20.1:
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.76.0
Qt version: 5.15.1
Kernel Version: 5.8.18-1-MANJARO
OS Type: 64 bit



In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3)
 of 2020-08-28 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Manjaro Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Saving file /tmp/test.org...
Wrote /tmp/test.org
Saving file /tmp/test.tex...
Wrote /tmp/test.tex
Processing LaTeX file test.tex...
PDF file produced.
Running /usr/bin/xdg-open /tmp/test.pdf...done

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: it_IT.UTF-8
  value of $LC_NUMERIC: it_IT.UTF-8
  value of $LC_TIME: it_IT.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail mule-util info tex-mode compile
shell latexenc cl-extra help-mode ox-odt rng-loc rng-uri rng-parse
rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok
nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox
org-element avl-tree generator ol-eww ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnir gnus-sum url url-proxy url-privacy url-expand url-methods
url-history mailcap shr url-cookie url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs json map
url-vars svg xml dom browse-url gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo parse-time iso8601
gnus-spec gnus-int gnus-range message rmc puny rfc822 mml mml-sec
password-cache epa derived epg epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
text-property-search seq byte-opt gv bytecomp byte-compile cconv
mail-utils mm-util mail-prsvr wid-edit ol-docview doc-view jka-compr
image-mode exif dired dired-loaddefs ol-bibtex bibtex ol-bbdb ol-w3m org
ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote
org-src ob-comint org-pcomplete pcomplete comint ansi-color ring
org-list org-faces org-entities time-date subr-x noutline outline
easy-mmode org-version ob-emacs-lisp ob-core ob-eval org-table ol
org-keys org-compat advice org-macs org-loaddefs format-spec find-func
cal-menu easymenu calendar cal-loaddefs cl-loaddefs cl-lib tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 192463 13711)
 (symbols 48 20487 1)
 (strings 32 76053 9166)
 (string-bytes 1 2456243)
 (vectors 16 32285)
 (vector-slots 8 365851 18818)
 (floats 8 220 130)
 (intervals 56 360 0)
 (buffers 1000 14))
Reply | Threaded
Open this post in threaded view
|

bug#44824: More info

gbiotti@gmail.com

Changing default program does not work: using evince instead of okular
-> same results.

Executing the command "xdg-open /path/to/file.pdf" in a terminal
(Konsole) works.

Executing the same command in Emacs via eshell DOES NOT WORK.





Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
"[hidden email]" <[hidden email]> writes:

> Executing the command "xdg-open /path/to/file.pdf" in a terminal
> (Konsole) works.
>
> Executing the same command in Emacs via eshell DOES NOT WORK.

What happens if you execute that command in Emacs via eshell?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com
Il 27/01/2021 04:36, Lars Ingebrigtsen writes:
> "[hidden email]" <[hidden email]> writes:
>
>> Executing the command "xdg-open /path/to/file.pdf" in a terminal
>> (Konsole) works.
>>
>> Executing the same command in Emacs via eshell DOES NOT WORK.
> What happens if you execute that command in Emacs via eshell?
>

The same as using C-c C-e l o
"The default PDF program (okular) appears to open (i see the icon, but not
the window) and closes without showing anything."




Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com
Il 28/01/2021 04:02, Lars Ingebrigtsen ha scritto:

> "[hidden email]" <[hidden email]> writes:
>
>> The same as using C-c C-e l o
>> "The default PDF program (okular) appears to open (i see the icon, but not
>> the window) and closes without showing anything."
> If I do
>
> $ xdg-open ./doc/lispintro/cons-2.pdf
>
> after `M-x shell', "Document Viewer" is opened as normal.
>
> You don't get any output from xdg-open or anything in the shell buffer?
>
> Glenn Morris <[hidden email]> writes:
>
>> Ref eg https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25234#8
>> https://bugzilla.gnome.org/show_bug.cgi?id=652262
>> https://gitlab.gnome.org/GNOME/glib/-/issues/1208
>> and others going back over a decade.
>> I think Emacs should have a PROBLEMS entry about this.
> Yeah, calling xdg-open (and expecting it not to exit) is a known
> problem, but here it seems that xdg-open doesn't even work from *shell*,
> which is very odd.
>

I have no more ideas.
The problem arise even exporting and opening html, so it's not the file
type.

Doing a better search I found this:
https://forum.manjaro.org/t/xdg-open-or-kde-open-doesnt-work-when-called-from-emacs/39918

Same problem, but without an answer.

If needed I can make a video of what happen (if so please explain where
to upload it).



Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com
In reply to this post by gbiotti@gmail.com
Il 28/01/2021 04:02, Lars Ingebrigtsen writes:

> "[hidden email]" <[hidden email]> writes:
>
>> The same as using C-c C-e l o
>> "The default PDF program (okular) appears to open (i see the icon, but not
>> the window) and closes without showing anything."
> If I do
>
> $ xdg-open ./doc/lispintro/cons-2.pdf
>
> after `M-x shell', "Document Viewer" is opened as normal.
>
> You don't get any output from xdg-open or anything in the shell buffer?
>
> Glenn Morris <[hidden email]> writes:
>
>> Ref eg https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25234#8
>> https://bugzilla.gnome.org/show_bug.cgi?id=652262
>> https://gitlab.gnome.org/GNOME/glib/-/issues/1208
>> and others going back over a decade.
>> I think Emacs should have a PROBLEMS entry about this.
> Yeah, calling xdg-open (and expecting it not to exit) is a known
> problem, but here it seems that xdg-open doesn't even work from *shell*,
> which is very odd.
>

More info:

As per bug 25234, using 'M-! xdg-open /tmp/test.pdf', 'M-& xdg-open
/tmp/test.pdf'
and 'M-& xdg-open /tmp/test.pdf && sleep 3' I get same results as reported.

If I try in eshell buffer 'xdg-open /tmp/test.pdf && sleep 3' my cursor
blinks
with the Okular icon for a few seconds and then nothing happens.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
"[hidden email]" <[hidden email]> writes:

>> Yeah, calling xdg-open (and expecting it not to exit) is a known
>> problem, but here it seems that xdg-open doesn't even work from *shell*,
>> which is very odd.
>
> More info:
>
> As per bug 25234, using 'M-! xdg-open /tmp/test.pdf', 'M-& xdg-open
> /tmp/test.pdf'
> and 'M-& xdg-open /tmp/test.pdf && sleep 3' I get same results as reported.

I'm not quite sure what you mean here.  Do you mean that
`M-! xdg-open /tmp/test.pdf' works fine, or that it fails?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com


Il ven 29 gen 2021, 05:51 Lars Ingebrigtsen <[hidden email]> writes:
"[hidden email]" <[hidden email]> writes:

>> Yeah, calling xdg-open (and expecting it not to exit) is a known
>> problem, but here it seems that xdg-open doesn't even work from *shell*,
>> which is very odd.
>
> More info:
>
> As per bug 25234, using 'M-! xdg-open /tmp/test.pdf', 'M-& xdg-open
> /tmp/test.pdf'
> and 'M-& xdg-open /tmp/test.pdf && sleep 3' I get same results as reported.

I'm not quite sure what you mean here.  Do you mean that
`M-! xdg-open /tmp/test.pdf' works fine, or that it fails?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

I get the same results reported in bug 25234. 'M-! xdg-open /tmp/test.pdf' works fine. I apologise for my english but it's not my mother language.


Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Geraldo Biotti <[hidden email]> writes:

> I get the same results reported in bug 25234. 'M-! xdg-open /tmp/test.pdf' works
> fine. I apologise for my english but it's not my mother language.

So:

This works:
M-! xdg-open /tmp/test.pdf RET

This doesn't work:
M-& xdg-open /tmp/test.pdf RET

This doesn't work:
M-x shell RET xdg-open /tmp/test.pdf RET

?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com


Il sab 30 gen 2021, 07:09 Lars Ingebrigtsen <[hidden email]> ha scritto:
Geraldo Biotti <[hidden email]> writes:

> I get the same results reported in bug 25234. 'M-! xdg-open /tmp/test.pdf' works
> fine. I apologise for my english but it's not my mother language.

So:

This works:
M-! xdg-open /tmp/test.pdf RET

This doesn't work:
M-& xdg-open /tmp/test.pdf RET

This doesn't work:
M-x shell RET xdg-open /tmp/test.pdf RET

?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Exactly. And it doesn't even "export as PDF and open file" in org-mode, which I think is a related problem.

Reply | Threaded
Open this post in threaded view
|

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

Maxim Nikulin
In reply to this post by Lars Ingebrigtsen
On 30/01/2021 15:42, Eli Zaretskii wrote:
>>
>> This works:
>> M-! xdg-open /tmp/test.pdf RET
>>
>> This doesn't work:
>> M-& xdg-open /tmp/test.pdf RET
>>
>> This doesn't work:
>> M-x shell RET xdg-open /tmp/test.pdf RET

Geraldo, "M-x shell" case is rather strange. Could you, please, confirm
ones more that okular window with the file content does not appear if
you call xdg-open from an *interactive* emacs shell buffer? The link to
an emacs-orgmode list message, that I have posted earlier, explains why
async-shell-command *may* fail while shell-command should work reliably.
I am really surprised by failure when command is executed in a [e]shell
buffer.

> How about asking the xdg-open developers to help us figure out the
> reason?  Or, failing that, debug xdg-open in the problematic
> situations to find out what fails there and why?  E.g., could it be
> that it fails because stdin/stdout is a PTY? what happens if you bind
> process-connection-type to nil when starting the async subprocess?

I do not think, it is xdg-open problem. It just calls kde-open5 that
spawns actual handler and immediately exits.



Reply | Threaded
Open this post in threaded view
|

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

Maxim Nikulin
On 30/01/2021 20:49, Eli Zaretskii wrote:

>>
>>> How about asking the xdg-open developers to help us figure out the
>>> reason?
>>
>> I do not think, it is xdg-open problem. It just calls kde-open5 that
>> spawns actual handler and immediately exits.
>
> I didn't say it was their problem, I suggested to ask them to help us
> understand why xdg-open doesn't work in those cases, under the
> assumption that they are familiar with their code better than us.

What kind of help do you expect from xdg-open developers? It is a shell
script, you could easily inspect it. I have posted already a command how
to trace its execution. However currently I am almost sure that it
merely calls 'kde-open5 /tmp/file.pdf'. The problem is that emacs does
not expect that kde-open5 and thus xdg-open exits instantly. 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. Some convenience function in emacs core would be nice but org
mode is compatible with older emacs releases. Thus the only option is to
change the org-open-files function.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Maxim Nikulin <[hidden email]>
> Date: Sat, 30 Jan 2021 22:58:06 +0700
> Cc: [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|

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

gbiotti@gmail.com
In reply to this post by Maxim Nikulin
Il 30/01/2021 14:31, Maxim Nikulin ha wrote:
On 30/01/2021 15:42, Eli Zaretskii wrote:

This works:
M-! xdg-open /tmp/test.pdf RET

This doesn't work:
M-& xdg-open /tmp/test.pdf RET

This doesn't work:
M-x shell RET xdg-open /tmp/test.pdf RET

Geraldo, "M-x shell" case is rather strange. Could you, please, confirm ones more that okular window with the file content does not appear if you call xdg-open from an *interactive* emacs shell buffer? The link to an emacs-orgmode list message, that I have posted earlier, explains why async-shell-command *may* fail while shell-command should work reliably. I am really surprised by failure when command is executed in a [e]shell buffer.


I confirm.
I can see the Okular icon appear and disappear immediately in the panel.
As mentioned I can make a video of everything, but I have no idea where to upload it.
If it is okay to make the video and you think it is useful please tell me which commands to execute for more information on the operating environment

How about asking the xdg-open developers to help us figure out the
reason?  Or, failing that, debug xdg-open in the problematic
situations to find out what fails there and why?  E.g., could it be
that it fails because stdin/stdout is a PTY? what happens if you bind
process-connection-type to nil when starting the async subprocess?

I do not think, it is xdg-open problem. It just calls kde-open5 that spawns actual handler and immediately exits.

Reply | Threaded
Open this post in threaded view
|

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

Bhavin Gandhi
On Sat, 30 Jan 2021 at 19:04, Maxim Nikulin <[hidden email]> wrote:

> […]
>
> Geraldo, "M-x shell" case is rather strange. Could you, please, confirm
> ones more that okular window with the file content does not appear if
> you call xdg-open from an *interactive* emacs shell buffer? The link to
> an emacs-orgmode list message, that I have posted earlier, explains why
> async-shell-command *may* fail while shell-command should work reliably.
> I am really surprised by failure when command is executed in a [e]shell
> buffer.
>

I was expecting something similar, surprisingly here is what I observed
on my system (with emacs -Q, GNOME and Evince — Document Viewer).

M-x eshell
$ xdg-open ~/Documents/test.pdf
[Nothing happens]

M-x shell
$ xdg-open ~/Documents/test.pdf
[Evince pops up with the PDF]

M-! xdg-open ~/Documents/test.pdf
[Evince pops up with the PDF]

M-& xdg-open ~/Documents/test.pdf
[Nothing happens]

Emacs: 27.1.91
GNOME: 3.38.3
xdg-open 1.1.3+
--
Warm Regards,
Bhavin Gandhi (bhavin192) | https://geeksocket.in



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> writes:

>> This doesn't work:
>> M-x shell RET xdg-open /tmp/test.pdf RET
>
> How about asking the xdg-open developers to help us figure out the
> reason?  Or, failing that, debug xdg-open in the problematic
> situations to find out what fails there and why?  E.g., could it be
> that it fails because stdin/stdout is a PTY? what happens if you bind
> process-connection-type to nil when starting the async subprocess?

I'm unable to reproduce the problem at all -- all the various ways of
calling xdg-open work fine for me (on this Debian bullseye laptop w/
Gnome Shell).

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

Maxim Nikulin
In reply to this post by Eli Zaretskii
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, [hidden email] 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 | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Maxim Nikulin <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>, [hidden email]
> Date: Sun, 31 Jan 2021 18:15:27 +0700
>
> 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.

What do you mean here by "actual handler" and "underlying handler"?

> 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.

Wouldn't it work to let-bind process-connection-type to nil around the
function that starts the async subprocess?

And I still don't understand why some people (like Lars) cannot
reproduce the problem at all -- the issue sounds like something that
should fail deterministically on any GNU/Linux system.  What am I
missing?



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
On Jan 31 2021, Eli Zaretskii wrote:

> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system.  What am I
> missing?

If xdg-open doesn't need to start the program itself, and sends the
request to an already running process instead, there won't be any
problem with the disappearing session.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system.  What am I
> missing?

The recipe said to start with `M-x shell' -- I wasn't able to reproduce
the problem there.  But with `M-x eshell' I can repeat the problem here,
too.

Perhaps the recipe was wrong?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



12