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.
