28 Jul
2012
28 Jul
'12
6:37 p.m.
Hi,
Sorry for my late reply. I was very busy the past days.
Darrell Anderson wrote:
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.
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)?
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.
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