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

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.


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

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?


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

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