GNU bug report logs -
#12972
24.3.50; Move `org-open-file' and associated code out of Org mode
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Fri, 23 Nov 2012 19:16:02 UTC
Severity: wishlist
Tags: patch
Found in version 24.3.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Maxim Nikulin <manikulin <at> gmail.com>
> Date: Fri, 2 Jul 2021 00:01:59 +0700
>
> --- a/lisp/net/mailcap.el
> +++ b/lisp/net/mailcap.el
> @@ -1177,7 +1177,23 @@ See \"~/.mailcap\", `mailcap-mime-data' and related files and variables."
> (shell-quote-argument (convert-standard-filename file))
> command
> nil t))
> - (start-process-shell-command command nil command)))
> + ;; Handlers such as "gio open" and kde-open5 start viewer in background
> + ;; and exit immediately. Avoid `start-process' since it assumes
> + ;; :connection-type 'pty and kills children processes with SIGHUP
> + ;; when temporary terminal session is finished (Bug#44824).
> + ;; An alternative is `process-connection-type' let-bound to nil for
> + ;; `start-process-shell-command' call (with no chance to report failure).
> + (make-process
> + :name "mailcap-view-file" :connection-type 'pipe :noquery t
> + :buffer nil ; "*Messages*" may be suitable for debugging
> + :sentinel (lambda (proc event)
> + (when (and (memq (process-status proc) '(exit signal))
> + (/= (process-exit-status proc) 0))
> + (message
> + "Command %s: %s."
> + (mapconcat #'identity (process-command proc) " ")
> + (substring event 0 -1))))
> + :command (list shell-file-name shell-command-switch command))))
I have two issues with this change:
First, you replace start-process-shell-command with make-process, and
I'm not sure I understand why. If all you want is to use pipes, why
not simply bind process-connection-type around the call to
start-process-shell-command? Does it not work for some reason?
And second, I'm not sure we should make this change unconditionally.
It isn't guaranteed that the handler will be one of those which have
the problem, is it? And with other handlers, this could be an
incompatible behavior change if the handler behaves differently when
its standard handles are connected to a pipe rather than a terminal
device. So I'd rather make this a conditional change, ideally only
when one of the affected handlers is used (assuming we can detect that
somehow).
Thanks.
This bug report was last modified 3 years and 299 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.