More about "intents": Several improvements to desktop files and caches

[Simon McVittie]

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.)

More precisely, the API specified in Debian is documented in
<http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.3>.
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"

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

    x-terminal-emulator -e vi /etc/hostname

is expected to work (and the Policy bug clarifies that that is the
intention).

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.

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.

    S