More about "intents": Several improvements to desktop files and caches
dominique.michel at vtxnet.ch
Wed Jan 8 13:45:41 PST 2014
Le Wed, 08 Jan 2014 18:52:32 +0000,
Simon McVittie <simon.mcvittie at collabora.co.uk> a écrit :
> On 08/01/14 18:15, Dominique Michel wrote:
> > I agree with you that a protocol is the way to get
> > interoperability, but if upstream is not following it, we don't get
> > it. In that case, xterm is the reference and its man page is clear,
> > we don't need "" after -e.
> (If you haven't already, I suggest reading about the distinction
> between shell argument parsing and exec()/posix_spawn()-style
> argument passing, and why the former often leads to security flaws,
> before going further with this line of thinking.)
It can be a good reason why fvwm add an exec call in the fvwm-crystal
function I was talking about.
> More precisely, the API specified in Debian is documented in
> It isn't completely clear from that description whether treating a
> single argument as a one-line shell script (which appears to be what
> you're trying to do) like this
> x-terminal-emulator -e "echo here is arbitrary shell; read"
No, that's not. I was talking about using
x-terminal-emulator -e mc /home/dom
and quoting the command for terminals that doesn't support xterm -e
> is expected to work (it does in xterm, but
> http://bugs.debian.org/648271 suggests that this is not required for
> an arbitrary x-terminal-emulator). It does imply that this
This is what I was referring to, sorry if it wasn't clear enough:
> x-terminal-emulator -e vi /etc/hostname
> is expected to work (and the Policy bug clarifies that that is the
> Please note that even within Debian, that policy says nothing about
> whether the underlying executable for any given terminal emulator has
> "xterm -e" semantics. *All alternatives for x-terminal-emulator* must
> have "xterm -e" semantics. That does *not* mean that running
> /usr/bin/konsole -e vi /etc/hostname
> must work; it only means that running
> /usr/bin/x-terminal-emulator -e vi /etc/hostname
> must work. A non-xterm terminal emulator is free to either have those
> semantics for -e and register itself as an x-terminal-emulator
> implementation (as xterm does); install a wrapper script which does,
> and register *that* as its x-terminal-emulator implementation (as
> gnome-terminal does); or not implement x-terminal-emulator at all.
> If an x-terminal-emulator implementation in Debian does not have those
> semantics, please open a Debian bug, quoting a command starting with
> "/usr/bin/x-terminal-emulator" that didn't work as you expected with
> that implementation.
I will do it for terminator. How can I find if another term provide or
not a x-terminal-emulator?
> If you want to define a terminal emulator API that is
> non-Debian-specific, in practice you're going to have to cope with
> terminal emulators that either implement it via some sort of wrapper
> or script because their own command-line parsing not compatible, or
> don't implement it at all.
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg