> Bash is not used, because the script has #!/bin/sh on the
> first line. If the script needs to be run with bash, the first line should
> not point to sh, but to bash instead. I do have Bash here.

I will change the declaration to bin/bash. I will look into bashisms and using the -e option.

> -rw-r--r-- 1 root root 8,6K mei 12 23:53 bookmarks.desktop
> -rw-r--r-- 1 root root  13K mei 12 23:53 history.desktop
> -rw-r--r-- 1 root root 7,8K mei 12 23:53 home.desktop
> -rw-r--r-- 1 root root 4,3K mei 12 23:53 metabar.desktop
> -rw-r--r-- 1 root root 1,8K mei 12 23:53 remote.desktop
> -rw-r--r-- 1 root root 6,5K mei 12 23:53 root.desktop
> -rw-r--r-- 1 root root 1,8K mei 12 23:53 services.desktop

Okay, now we know the cause. :-)

> No clue why those files are owned by root in my profile. Do
> you think it would be possible to enhance the script for permission
> problems and suggest the user to run the script as root (with the right
> parameters to update the problematic profile).

Probably possible, although I'll have to look into an optimal method for that. For the moment I'm providing a link to an updated script that provides a reminder message to check permissions, as well as some more error checking and general fine-tuning.

Here is the link to the updated script:

http://humanreadable.nfshost.com/trinity/patches/r14-xdg-update

I'm not uploading yet to GIT as I'd appreciate you running some nominal tests --- for the updated messages and to ensure the script does not break outright. :-) I'll upload to GIT upon receiving your affirmative reply. If you haven't yet changed the ownership of those files, then testing the updated version will help. The updated script works here, but your perspective provides a fresh pair of eyes and a different set of needs to better test.

If you look at the beginning of the script, you'll see a "TODO" reminder that permissions and administrative locks need to be addressed. That item has been in the script from the beginning. :-) At the moment I don't know how we should address that problem. Running the script as root is an option, but users need to run the script as root while inheriting the user's environment. Otherwise the script will run against root's profile rather than the user's. We do need to address this because in enterprise environments where files are locked then only root can run the script anyway. I'm open to ideas.

Darrell