"Name" key value in desk. entry spec collides with file names, could misguide users?

[Diego Calleja]

[I saw your answer at the web archives, I've not got a reply personally or from the list, I 
suppose your message got lost]

Waldo Bastian bastian at kde.org
Tue Mar 15 06:14:51 PST 2005

>> On Tuesday 15 March 2005 14:31, Diego Calleja wrote:
>> Because it fails at several levels. To start with, you can't put a
>> misleading icon that can misguide to even some clueful users
>>
>> That script will not work because the MUA you're using will (or should) not
>> set the +x bit in the permissions field, and doublecliking it won't work.
>> That's the failure with .desktop files: We CAN'T stop them being
>> executable. They're executable by themselves as long as they have a exec
>> key in them.
>
> Do you think it would help to require +x bits on .desktop files?

Indeed, your solution seemms to me the best solution available, making it behave just
like a "shell script", if the .desktop file doesn't have the +x bit, ignore the Exec
field...or ignore *all* fields? (ie: handle it as a normal file, showing the .desktop extension,
the real name, etc). That would indeed assure us that nobody is going to click a evil
malformed .desktop file because the mail client, or the browser, is not going to save the
file with +x.

Also if offers a easy migration path from .desktop files already constructed because the
format of the desktop files doesn't change, just the scope of when they must be
handled and can be fixed easily (and everybody would be "forced" to handle it when/if
nautilus and konqueror don't open the -x .desktop files by default so no old .desktop
files would remain unchanged)

Another thing that would be interesting to consider (even with the previous modifications
to the spec) is if it should be OK to handle Exec keys like:
Exec=command1; command2; command3; command4
IMHO the essence of the Exec key it's "run a command", not "be a small shell script",
and should be limited.