23 Jul
2012
23 Jul
'12
1:28 p.m.
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