Hi,

Sorry for my late reply. I was very busy the past days.

Darrell Anderson wrote:
>> 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.

Yes, the alternative would be to write the script against sh instead of
bash, but I don't really know if that would have a big advantage.


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

When I run it (inside a Trinity session), I get this message "Unable to
determine TDE base directory.". I suppose this means that it cannot find
the profile directory, but the message is not so clear by itself. Could
you update this message (and maybe similar messages) so it gives a
little hint what check is actually being done (and maybe propose a
solution)?


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

Done that, see the results above.


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

Why does the script depend on the user's environment? I would say that
it should not make any assumptions about the environment whatsoever.
Does the script need any more information than just the path to a
Trinity profile? Shouldn't this information always be passed on to the
script through a parameter?

Thanks a lot!
Julius