bug#25234: 25.1; call-process vs. start-process and xdg-open

bug#25234: 25.1; call-process vs. start-process and xdg-open

[Justin Burkett]

[-- Attachment #1: Type: text/plain, Size: 5401 bytes --]

I'm not sure if this is a bug or is intended. Also, I am no expert in
this area, so forgive me.

Here is what I am seeing.  The behavior with `call-process` vs
`start-process` is the same as the behavior with `shell-command` vs
`async-shell-command`, so I'll use the latter to demonstrate. evince is
my default pdf program, and "xdg-open test.pdf" is fine in a shell
outside of emacs.

  1. If I do `M-! xdg-open test.pdf`, test.pdf opens fine and remains
  open.

  2. If I do `M-& xdg-open test.pdf`, I get a message that "xdg-open
  test.pdf" finished with no program opening.

  3. If I do `M-& xdg-open test.pdf && sleep 3`, the pdf opens for 3
  seconds and closes.

So clearly emacs is killing evince when the command exits. This is
logical if it's killing a whole process tree and evince is a
subprocess,
but it does not seem consistent with how `xdg-open` works in a shell.

Running `xdg-open test.pdf` in a shell does not make evince a
subprocess
of the shell so killing the shell does not kill evince.

Furthermore what's confusing to me is that the start-process version
seems to work fine for others, given the way crux-open-with is defined
in the crux package, which is on github. See
https://github.com/bbatsov/crux/issues/37.




In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.4)
 of 2016-12-15 built on buildvm-30.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11900000
System Description: Fedora release 25 (Twenty Five)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-
png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS
NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

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
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
xdg-open test.pdf: finished.
previous-line: Beginning of buffer
xdg-open test.pdf && sleep 2: finished.
Quit

(evince:8710): Gtk-WARNING **: Allocating size to EvSidebar
0x55f81e9ec6c0 without calling gtk_widget_get_preferred_width/height().
How does the code know the size to allocate?

(evince:8710): Gtk-WARNING **: Negative content width -5 (allocation
19, extents 12x12) while allocating gadget (node label, owner GtkLabel)
Quit
xdg-open test.pdf: finished.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils shell pcomplete comint
ansi-color ring time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame 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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting xwidget-
internal
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 90925 6233)
 (symbols 48 20244 0)
 (miscs 40 80 121)
 (strings 32 15817 4612)
 (string-bytes 1 465510)
 (vectors 16 12531)
 (vector-slots 8 438289 3095)
 (floats 8 168 197)
 (intervals 56 275 13)
 (buffers 976 21))

[-- Attachment #2: Type: text/html, Size: 21266 bytes --]

bug#25234: 25.1; call-process vs. start-process and xdg-open

[Glenn Morris]

The issue (I assume) is that xdg-open creates its new process (evince,
whatever) by forking. Then the original xdg-open process exits, which as
far as Emacs knows means it is done.

See eg https://bugzilla.gnome.org/show_bug.cgi?id=652262

bug#25234: 25.1; call-process vs. start-process and xdg-open

[Justin Burkett]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Thank you for the link. That seems to be exactly the issue, so you can
close this (or I'll do it when I figure out how).
On Mon, Dec 19, 2016 at 3:28 PM Glenn Morris <rgm@gnu.org> wrote:

>
> The issue (I assume) is that xdg-open creates its new process (evince,
> whatever) by forking. Then the original xdg-open process exits, which as
> far as Emacs knows means it is done.
>
> See eg https://bugzilla.gnome.org/show_bug.cgi?id=652262
>

[-- Attachment #2: Type: text/html, Size: 899 bytes --]