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