bug#44824: 27.1; Org export as pdf and open file does not open it
On 31/01/2021 23:33, Eli Zaretskii wrote: 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? ... Well, I think we should try this, because if it works, it will show us a way to fix the problem. (I don't see how lexical-binding could interfere with let-binding.) It is not a great problem to use make-process: https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00364.html I think that at least a :sentinel should be added to improve error reporting. The code just before these lines has another problem (I hope it is really rare): https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00353.html I would avoid shell since direct execution of the handler should be more robust, e.g. quoting of arguments is not necessary. Unfortunately RFC on mailcap states that command is executed by shell. On the other hand only a few of viewer entries have commands that could not be handled without shell.
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Maxim Nikulin > Date: Sun, 31 Jan 2021 22:57:57 +0700 > Cc: 44...@debbugs.gnu.org > > >> 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? > > Sorry, for me it easier to reason how to express it in terms of system > calls and terminal process groups than if let-bind could override a > variable when lexical-bind is set to true. Well, I think we should try this, because if it works, it will show us a way to fix the problem. (I don't see how lexical-binding could interfere with let-binding.)
bug#44824: 27.1; Org export as pdf and open file does not open it
On 31/01/2021 22:05, Eli Zaretskii wrote: From: Maxim Nikulin 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"? - actual handler: okular, evince, etc. - underlying handler is what xdg-open actually calls: kde-open5, "gio open", etc. and that maps file type to particular .desktop (or mailcap) handler. 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? Sorry, for me it easier to reason how to express it in terms of system calls and terminal process groups than if let-bind could override a variable when lexical-bind is set to true. 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? On 31/01/2021 22:17, Andreas Schwab wrote: > > 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. I have been tempting to say that it is a race (either request is completed before SIGHUP or not) since Christopher Miles posted a link to stackexchange and I have realized the actual effect of an antidaemonizing cast I noticed earlier in a package related to org mode. On the other hand, I am not familiar with kde and gnome internals. I guess they could use a kind of server processes but I have no idea how to arrange parts for a convincing demonstration.
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Andreas Schwab > Cc: Maxim Nikulin , 44...@debbugs.gnu.org, > gbio...@gmail.com > Date: Sun, 31 Jan 2021 16:17:46 +0100 > > 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. Ah, okay. Lars, could this be what happens on your system?
bug#44824: 27.1; Org export as pdf and open file does not open it
Eli Zaretskii 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
bug#44824: 27.1; Org export as pdf and open file does not open it
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, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Maxim Nikulin > Cc: Eli Zaretskii , gbio...@gmail.com > 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?
bug#44824: 27.1; Org export as pdf and open file does not open it
On Sun, Jan 31, 2021 at 06:15:27PM +0700, Maxim Nikulin wrote: > 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 [...] > 2221 16:59:43.717489 +++ exited with 0 +++ > 2229 16:59:43.719228 +++ killed by SIGHUP +++ Good catch. > On 31/01/2021 16:09, to...@tuxteam.de wrote: > >This chaotic behaviour gives me the impression that it's an > >environment thing [...] > 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. Yes, but in this case it seems I was barking up the wrong tree :) Cheers & thanks - t signature.asc Description: Digital signature
bug#44824: 27.1; Org export as pdf and open file does not open it
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 */
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 */
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, to...@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.
Re: bug#44824: 27.1; Org export as pdf and open file does not open it
On Sun, Jan 31, 2021 at 06:39:40PM +1100, Tim Cross wrote: > > Lars Ingebrigtsen writes: > > > Eli Zaretskii 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). > > For me, I get > > M-! xdg-open /tmp/test.pdf works > M-x shell xdg-open /tmp/test.pdf works > M-& xdg-open /tmp/test.pdf fails > M-x eshell xdg-open /tmp/test.pdf fails > > The two which fail do not report any error - just now pdf viewer open. > > I also have no problems with org export menu when I choose export to pdf > and open. > > This was on a Ubuntu 20.10, latest Emacs 27 (27.5.91), mate DE and > default shell zsh. 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. One var to look for would be, of course, PATH, but I don't know what other environment variables `xdg-open' looks at; perhaps USER, HOME are relevant, perhaps more. May be comparing what `env' says under those different invocations could shed some light. Cheers - t signature.asc Description: Digital signature
Re: bug#44824: 27.1; Org export as pdf and open file does not open it
Lars Ingebrigtsen writes: > Eli Zaretskii 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). For me, I get M-! xdg-open /tmp/test.pdf works M-x shell xdg-open /tmp/test.pdf works M-& xdg-open /tmp/test.pdf fails M-x eshell xdg-open /tmp/test.pdf fails The two which fail do not report any error - just now pdf viewer open. I also have no problems with org export menu when I choose export to pdf and open. This was on a Ubuntu 20.10, latest Emacs 27 (27.5.91), mate DE and default shell zsh. -- Tim Cross
bug#44824: 27.1; Org export as pdf and open file does not open it
Eli Zaretskii 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
bug#44824: 27.1; Org export as pdf and open file does not open it
On Sat, 30 Jan 2021 at 19:04, Maxim Nikulin 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
bug#44824: 27.1; Org export as pdf and open file does not open it
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.
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Maxim Nikulin > Date: Sat, 30 Jan 2021 22:58:06 +0700 > Cc: 44...@debbugs.gnu.org > > 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?
bug#44824: 27.1; Org export as pdf and open file does not open it
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.
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Maxim Nikulin > Date: Sat, 30 Jan 2021 20:31:53 +0700 > Cc: gbio...@gmail.com > > > 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. 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.
bug#44824: 27.1; Org export as pdf and open file does not open it
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.
bug#44824: 27.1; Org export as pdf and open file does not open it
> From: Lars Ingebrigtsen > Date: Sat, 30 Jan 2021 07:09:50 +0100 > Cc: 44...@debbugs.gnu.org > > 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 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?
bug#44824: 27.1; Org export as pdf and open file does not open it
Il sab 30 gen 2021, 07:09 Lars Ingebrigtsen ha scritto: > Geraldo Biotti 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.
bug#44824: 27.1; Org export as pdf and open file does not open it
Geraldo Biotti 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
bug#44824: 27.1; Org export as pdf and open file does not open it
Il ven 29 gen 2021, 05:51 Lars Ingebrigtsen writes: > "gbio...@gmail.com" 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. >
bug#44824: 27.1; Org export as pdf and open file does not open it
"gbio...@gmail.com" 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
bug#44824: 27.1; Org export as pdf and open file does not open it
On 28/01/2021 18:31, gbio...@gmail.com wrote:
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.
If I correctly get what you describe as "blinks", it could last for some
time after process failure. On the other hand I am surprised that no
other diagnostics is shown as a KDE dialog or as an error message in the
eshell buffer. In the case of eshell, it is likely another problem, not
killing handler with SIGHUP due to instantly closed pty.
What happens if you run the following commands in the Emacs *eshell
buffer* (with an existing PDF file, of course)? In particular I am
interested in output appeared in the buffer.
1. okular /tmp/test.pdf
2. kde-open5 /tmp/test.pdf
3. sh -x /usr/bin/xdg-open /tmp/test.pdf
I'm almost sure that okular is configured as the handler, but just to
confirm it:
4. xdg-mime query default application/pdf
I assume that PDF file is a valid one (not corrupted, not empty, not
accessible due to file permissions, etc.) since okular is able to report
such problems.
You could also attach to emacs process with strace, try to launch
handler, kill strace, and inspect log file which processes are spawned
("execve" lines) and their exit codes. Run strace from ordinary terminal
(not from emacs) with proper process ID:
strace -o /tmp/emacs.strace -f -s 128 -tt -p PID_OF_EMACS_PROCESS
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 28/01/2021 04:02, Lars Ingebrigtsen ha scritto: "gbio...@gmail.com" 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 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).
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 28/01/2021 04:02, Lars Ingebrigtsen writes: "gbio...@gmail.com" 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 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.
bug#44824: 27.1; Org export as pdf and open file does not open it
I hope, the following link to another emacs-orgmode mail list archive will not be mangled by the debbugs web interface, unlike the previous one: https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00327.html
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 27/01/2021 04:36, Lars Ingebrigtsen writes: "gbio...@gmail.com" 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."
bug#44824: 27.1; Org export as pdf and open file does not open it
"gbio...@gmail.com" 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 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. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug#44824: 27.1; Org export as pdf and open file does not open it
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.
Re: bug#44824: 27.1; Org export as pdf and open file does not open it
On 27/01/2021 10:36, Lars Ingebrigtsen wrote: Executing the command "xdg-open /path/to/file.pdf" in a terminal (Konsole) works. The problem may be related to SIGHUP sent to children due to pty created by emacs and closed as soon as the handler exits: https://orgmode.org/list/ru4d75$11sc$1...@ciao.gmane.io/ As a workaround you could try to set another handler for PDF files in mailcap, e.g. okular directly without xdg-open wrapper. Handler should not try to launch actual application in background with immediate exit. Currently start-process elisp function is used internally in org-open-file. Low level (make-process :connection-type 'pipe ...) should allow to avoid pty+SIGHUP problem. Maybe there are some consequences of such change that I am not aware of.
bug#44824: 27.1; Org export as pdf and open file does not open it
"gbio...@gmail.com" 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
