Relative paths in .desktop, .service files' Exec= lines
d at generaldevelopment.com.au
Fri Jul 1 05:32:33 UTC 2016
I've been following this list for only a few weeks, so all this is rather
new to me (as was the surprise realisation, a little while back, that
relative paths weren't already supported!), but I would appreciate some
clarification with this relative paths proposal. I agree that support for
relative paths would be very, very, nice to have.
> One subtlety of the phrasing is that a single .desktop or .service file
> might be visible in more than one directory thanks to symlinks, hard
> links or bind mounts. Thiago's phrasing makes it specific that it is the
> directory that actually appeared in the .desktop or .service search path
> that matters, and not any of the same file's other apparent locations.
What is the specific behaviour being proposed here. i.e. how might you
determine which path 'matters' without sacrificing some of the convenient
relocatability that relative paths provide?
To me it would seem that the most sensible approach for dealing with
symbolic links would be to first determine that they *are* symbolic links
and follow them to the actual file they point to, then parse in the context
of that physical file. That way the .desktop file and all symlinks (created
by the user, or otherwise) would be guaranteed to work with identical
behaviour. Doing things like hard links or bind-mounts of .desktop files
wouldn't work with this approach, but in practical terms would that
actually be a problem? I'm not convinced that anyone in their right mind
would bind-mount a single .desktop file in isolation without the context of
its target directory structure and expect it to work anyway.
General Development Systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg