Darrell Anderson wrote:
>> 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)?
> 
> The message means the script is unable to locate the TDE bin directory, the directory containing all of the TDE executables, usually /opt/trinity/bin.
> 
> If you receive that error message then I'll guess you are running the script from a location different from that directory, such as $HOME/bin.
> 
> Please feel welcomed to improve the message string.

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.


>> 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?
> 
> The script does not depend upon the user's environment per se. That is, the script does not presume the existence of any TDE environment variables.
> 
> Currently the script is intended to be run from within starttde, although the script accepts the "force" parameter when run manually from a console or terminal. Running from within starttde means the script inherits the user's file and directory permissions. When files or directories in the user's TDE profile are administratively locked, then the script fails to update those files.
> 
> In your case you found some files owned by root, although you did not know how that happened. How should the script deal with such files? Likewise with files/directories that are administratively locked.

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


> 
> The script could be modified to accept additional parameters. I'll chew on that.
> 
> Bear in mind that nobody has helped test the script other than you. Like any software I am unable to conceive all usage environments and corner cases. If more people got involved perhaps we'd see improvements. :-)

Sure, that's why I try to give feedback :)


> Please test the latest version from GIT and --- for now --- install the script to $PREFIX/bin. Since our last conversation I've added more information in the messages, tried to add more error trapping, etc.

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.

Here is the full output:
[r14-xdg-update] Performing a profile update for Trinity release R14 XDG
compliance.
[r14-xdg-update] Profile directory: /home/julius/.trinity
[r14-xdg-update] Updating *.desktop files.
[r14-xdg-update] Updating references of
/opt/trinity/share/applications/kde to share/applications/tde.
[r14-xdg-update] Updating user-defined keyboard shortcuts in khotkeysrc.
[r14-xdg-update] Updating some text strings in khotkeysrc.
[r14-xdg-update] Updating some text strings in kglobalshortcutsrc.
[r14-xdg-update] Updating user-defined app preferences in profilerc.
[r14-xdg-update] Updating kicker/panel customizations in kickerrc.
[r14-xdg-update] Updating Quick Launch applet.
[r14-xdg-update] Quick Launch is not installed.
[r14-xdg-update] Updating Autostart files.
[r14-xdg-update] R14 XDG updates completed successfully.

Thanks,
Julius