<div dir="ltr">My proposal is that a relative entry should be specified to "fail to execute."<div>Unless there is a really, really good use case (other than "users sometimes mistakenly write this") then there's no reason to allow any kind of ambiguity.<br></div><div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font face="courier new, monospace"><br><br><br><font>Sincerely,</font><br><br><font>Jon Watte</font><br><br><br>--<br>"<span style="color:rgb(0,0,0)">I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson</span></font></div></div>
<br><div class="gmail_quote">On Mon, Sep 8, 2014 at 5:23 AM, Simon McVittie <span dir="ltr"><<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On <<a href="https://bugs.freedesktop.org/show_bug.cgi?id=44030" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=44030</a>>, we've been<br>
trying to work out what the semantics of a non-absolute Exec key in<br>
D-Bus services should be. I would like it to be the same as in XDG<br>
desktop entries (whatever that is), which is not currently completely<br>
specified.<br>
<br>
In particular, Ralf Habacker (maintainer of D-Bus on Windows) would like<br>
D-Bus session .service files to be "relocatable", because fixed paths<br>
like /usr are not something that exists on Windows. I would like to<br>
avoid having the semantics of .service files on Windows and Unix be<br>
completely different, so I would like to have something that can work on<br>
Unix too, hence involving XDG rather than doing a Windows-specific change.<br>
<br>
There are three cases:<br>
<br>
1) absolute (starts with / on Unix, [/\] or [A-Za-z]:[/\] on Windows)<br>
<br>
This is easy and obvious. Exec=/usr/bin/foo executes /usr/bin/foo,<br>
Exec=C:\\mingw\\bin\\bar.exe executes C:\mingw\bin\bar.exe.<br>
<br>
2) no path separator (no / on Unix, no [/\] on Windows)<br>
<br>
For desktop entries on Unix, this is well-defined: Exec=foo searches the<br>
PATH for foo, the same way execvp() would do.<br>
<br>
For D-Bus services, this is not currently specified. Implementation<br>
detail: dbus-daemon on Unix uses execv(), so it will look in its current<br>
working directory, whatever that happens to be; dbus-daemon on Windows<br>
fails to execute the service.<br>
<br>
I think a reasonable behaviour would be to use execvp() on Unix and<br>
SearchPath(NULL, "foo.exe", ...) on Windows.<br>
<br>
3) contains a path separator but is relative<br>
<br>
This is not currently in either specification: it is unspecified what<br>
Exec=../bin/foo or Exec=./foo would do.<br>
<br>
Reasonable possibilities include:<br>
<br>
* it's relative to the directory containing the executable that is<br>
  interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin<br>
<br>
* it's relative to the getcwd() of the process that is interpreting<br>
  the file, i.e. normally / or $HOME<br>
<br>
* it's relative to the directory containing the file itself,<br>
  i.e. normally /usr/share/applications<br>
<br>
(Implementation detail: whichever directory is chosen, on Unix, it<br>
should be relatively straightforward to make Unix dbus-daemon chdir() to<br>
it after fork() but before execvp(), since POSIX.1-2004 says chdir(2) is<br>
async-signal-safe. That would make relative paths do the expected thing.)<br>
<br>
Thoughts?<br>
<br>
Regards,<br>
    S<br>
_______________________________________________<br>
dbus mailing list<br>
<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dbus</a><br>
</blockquote></div><br></div>