2 Aug
2012
2 Aug
'12
8:15 a.m.
Darrell Anderson wrote:
I'm not sure what you mean with "the information", but there must be a
clear reason why the script needs to know where the Trinity binaries
are. If this is not clear, we should find out about it.
I just looked at the diff. The way it is implemented doesn't seem right
and could very easily break non-regular situations.
The script should never check the UID or even presume that it should be
run as root for certain situations.
Imagine for instance that the script is run as a non-root user who has
write access to another user's profile directory.
I think the script should always try to update a given profile directory
as much as it can and display errors for any problems it encounters.
Then there could be a suggestion to run it as root in case file
permissions appear to be a problem.
I also see that the script expects environment variables to be set. Is
there any special reason to not use regular parameters?
In starttde, the script seems to be executed with this line:
"sh $TDEDIR/bin/r14-xdg-update"
I would expect something like this instead:
"r14-xdg-update --userdir $TDEHOME --auto"
This allows the script to be ran with another interpreter than sh (the
used interpreter can just be changed at the top of the file) and learn
directly about what starttde already knows.
Is there a special reason it is not done like that?
As I explained, I'm interested to know if there is a special reason to
only allow the script to be ran as root against any directory.
Thanks!
Julius
Why does the
script need to know this directory? If the
script depends on a specific binary included with Trinity, I think a more
suitable error would be "... not found", which would indicate that
this binary needs to be in the PATH environment.
The information is not always dependably knowable. For the same reason starttde checks
and sets the same type of information if not discoverable in the user's environment.
Just a
suggestion to run the right command as root seems
appropriate. Something along the lines of:
Some files in your Trinity profile cannot by modified.
(Ideally a list would appear as well.) Please run "r14-xdg-update --profile
/home/julius/.trinity" as root to finish updating the
profile. (In case the --profile parameter would be used to specify a
profile.)
In the latest update I attempted to support automated execution and running as root.
Now (without
me doing any manual changes), the script completes
successfully. Somehow it seems to miss the
/home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/*.desktop
files now, because they are still owned by root and also still contain
X-KDE.
Hopefully the latest version does not miss those files, or any files owned by root.
I updated the script in commit 31f926d9.
You now can run as root against any directory. There is a short help notice at the
beginning of the script how to do that. In your case, run the script under your normal
user account. Hopefully you'll see an error message that the aforementioned files were
not updated. The stdout message will list a text file that list the problematic files.
Then with those files still owned by root, run the script as root and the files should
then update.