It seems the migration script is being ran every single time I log on now. As a result, I see nothing on the screen for a long period of time. After a while a dialog pops up, which indicates there is an issue with some desktop link files in my profile.
Could somehow the migration process be announced/displayed/indicated so that it is clear what is going on? Why could the script have problems with updating desktop links inside my profile? The diagnostic information seems limited.
Thanks, Julius
It seems the migration script is being ran every single time I log on now. As a result, I see nothing on the screen for a long period of time. After a while a dialog pops up, which indicates there is an issue with some desktop link files in my profile.
Could somehow the migration process be announced/displayed/indicated so that it is clear what is going on? Why could the script have problems with updating desktop links inside my profile? The diagnostic information seems limited.
Just to make sure we are talking about the same script, the migration script is called migratedkde3 and converts an existing KDE3 profile directory to Trinity. The migratekde3 script is not run from anywhere and has to be run manually. Using the script is intended to be optional.
The r14-xdg-update script updates profile configuration files with recent XDG changes and is intended to be run only once from starttde.
I believe you are referring to the r14-xdg-update script. :-)
When the r14-xdg-update script is run, the stdout messages should appear in the user's xsession log. X popup dialogs appear when a validation test fails. At this point of development, the popup means either the updating failed or the test used to validate the update is incorrect or flawed.
If there are any failures that prevent the script from creating a "true" key entry in kdeglobals, then yes, the script gets run every time a user runs starttde. As there currently only a handful of us running Trinity from GIT, there are only a few us actually testing this process. :-)
Seems we have two problems to resolve here. One, what file(s) in your profile are proving problematic and don't update as expected, or are updating but the validation test fails to recognize? We need more information about that to revise the script for corner cases. We need to know the exact dialog message string, which will help know which section is failing.
Two, I'm open to any improvement ideas. :-) Originally I thought about popping a dialog that the update is starting, but I decided against that because for a significant majority of people the changes should work transparently and there is no need to bother users with dialogs for this one-time update.
There is an exception right now, of course, because the script is still considered beta and bugs are likely.
I still lean that way toward no dialog for the first-time run. Therefore I revised the script so that when one of the update snippets fail, the script tags the kdeglobals key with validation test failure rather than "true" or "false." Then with the next login the script displays a dialog that the script is running again and will run every time unless the problem is resolved, and to notify an administrator or take appropriate adminstrative action.
You wrote "updating desktop links." Without the full message string, there are two possible points you might be referring. One message is "There was an error with creating a new sym link for $LINK." The other point is "Some Trinity profile R14 XDG compliance updates failed.\n\n(Check *.desktop files for 'KDE;'.)"
For the former message, we need to know which link could not be created and then post a copy of that link. For the latter message, perform the following in your profile:
find "$PROFILE_DIR" -name "*.desktop" -exec grep -l "KDE;" {} ;
I added some quotation marks in the link snippet and possibly that might resolve your specific failure. Without the quotation marks the ln command could not resolve spaces in file names.
I pushed the script changes in commit 81dc4c09. You don't need to rebuild a new tdebase package: grab the latest copy of r14-xdg-update from GIT and simply copy to $PREFIX/bin.
Please keep me informed. :-)
Darrell
Darrell Anderson wrote:
It seems the migration script is being ran every single time I log on now. As a result, I see nothing on the screen for a long period of time. After a while a dialog pops up, which indicates there is an issue with some desktop link files in my profile.
Could somehow the migration process be announced/displayed/indicated so that it is clear what is going on? Why could the script have problems with updating desktop links inside my profile? The diagnostic information seems limited.
Just to make sure we are talking about the same script, the migration script is called migratedkde3 and converts an existing KDE3 profile directory to Trinity. The migratekde3 script is not run from anywhere and has to be run manually. Using the script is intended to be optional.
The r14-xdg-update script updates profile configuration files with recent XDG changes and is intended to be run only once from starttde.
I believe you are referring to the r14-xdg-update script. :-)
Correct!
When the r14-xdg-update script is run, the stdout messages should appear in the user's xsession log. X popup dialogs appear when a validation test fails. At this point of development, the popup means either the updating failed or the test used to validate the update is incorrect or flawed.
The only output I see there (I guess the -e is a small bug?). [r14-xdg-update] -e Performing a profile update for Trinity release R14 XDG compliance. [r14-xdg-update] -e Updating *.desktop files. [r14-xdg-update] -e Updating references of /opt/trinity/share/applications/kde to share/applications/tde. [r14-xdg-update] -e Updating user-defined keyboard shortcuts in khotkeysrc. [r14-xdg-update] -e Updating user-defined app prefernces in profilerc. [r14-xdg-update] -e Updating kicker/panel customizations in kickerrc. [r14-xdg-update] Updating Autostart files.
If there are any failures that prevent the script from creating a "true" key entry in kdeglobals, then yes, the script gets run every time a user runs starttde. As there currently only a handful of us running Trinity from GIT, there are only a few us actually testing this process. :-)
Seems we have two problems to resolve here. One, what file(s) in your profile are proving problematic and don't update as expected, or are updating but the validation test fails to recognize? We need more information about that to revise the script for corner cases. We need to know the exact dialog message string, which will help know which section is failing.
Two, I'm open to any improvement ideas. :-) Originally I thought about popping a dialog that the update is starting, but I decided against that because for a significant majority of people the changes should work transparently and there is no need to bother users with dialogs for this one-time update.
There is an exception right now, of course, because the script is still considered beta and bugs are likely.
I still lean that way toward no dialog for the first-time run. Therefore I revised the script so that when one of the update snippets fail, the script tags the kdeglobals key with validation test failure rather than "true" or "false." Then with the next login the script displays a dialog that the script is running again and will run every time unless the problem is resolved, and to notify an administrator or take appropriate adminstrative action.
"Some Trinity profile R14 XDG compliance updates failed.\n\n(Check *.desktop files for 'KDE;'.)"
For the former message, we need to know which link could not be created and then post a copy of that link. For the latter message, perform the following in your profile:
find "$PROFILE_DIR" -name "*.desktop" -exec grep -l "KDE;" {} ;
That is the message I get indeed. I ran this command: find /home/julius/.trinity/ -name "*.desktop" -exec grep -l "KDE;" {} ;
But there was no output. Here is a screenshot of it: https://lh3.googleusercontent.com/--uMdK0xwgtU/UAxGk6mg6AI/AAAAAAAAA6Y/8splt...
I added some quotation marks in the link snippet and possibly that might resolve your specific failure. Without the quotation marks the ln command could not resolve spaces in file names.
I pushed the script changes in commit 81dc4c09. You don't need to rebuild a new tdebase package: grab the latest copy of r14-xdg-update from GIT and simply copy to $PREFIX/bin.
I'll see if I can fetch the new script. I'm a bit surprised that the script immediately starts executing when I run it now. This doesn't really make it suitable for specific diagnosing or using it to update another user's profile. Could it just display some instructions on how it can be used when it's run without any parameters?
Thanks! Julius
The only output I see there (I guess the -e is a small bug?).
Hmm. Works fine here. Possibly a bashism? Is bash used on your system when running starttde? If not, then is the -e option supported in the shell you are using?
[r14-xdg-update] -e Performing a profile update for Trinity release R14 XDG compliance. [r14-xdg-update] -e Updating *.desktop files. [r14-xdg-update] -e Updating references of /opt/trinity/share/applications/kde to share/applications/tde. [r14-xdg-update] -e Updating user-defined keyboard shortcuts in khotkeysrc. [r14-xdg-update] -e Updating user-defined app prefernces in profilerc. [r14-xdg-update] -e Updating kicker/panel customizations in kickerrc. [r14-xdg-update] Updating Autostart files.
Excepting the "-e" bug, those all are expected output messages.
That is the message I get indeed. I ran this command: find /home/julius/.trinity/ -name "*.desktop" -exec grep -l "KDE;" {} ;
But there was no output. Here is a screenshot of it: https://lh3.googleusercontent.com/--uMdK0xwgtU/UAxGk6mg6AI/AAAAAAAAA6Y/8splt...
Okay, so the problem is a *.desktop file. :-)
The reason there was no output whe you ran the find/grep command manually is we used the wrong text string for grep. Based upon the X dialog popup in the screen grab, the appropriate search would be this:
find /home/julius/.trinity -name "*.desktop" -exec grep -l "X-KDE" {} ;
The grep -l option will list the problematic file. Eliminate the -l option to view the problematic lines in that file. I'm curious to see what the failure might be.
I'll see if I can fetch the new script. I'm a bit surprised that the script immediately starts executing when I run it now. This doesn't really make it suitable for specific diagnosing or using it to update another user's profile. Could it just display some instructions on how it can be used when it's run without any parameters?
When the script is run the first time from within starttde, there are only the stdout (redirected to an xsession log when available) and X dialog messages. When the script is run a subsequent time, and the first execution was run successfully, the only way to run the script thereafter is manually from the command line. When a user tries this, the script detects the contents of kdeglobals and reports the script has been run previously and adds a note that to run the script multiple times requires using the "force" parameter.
With a failed execution, the script runs every time from within starttde. The last version I uploaded added an X dialog popup reflecting this problem and includes an "error code." The error code is nothing more than a shortcut method to identify which snippets in the script are causing failures. When that happens we (or an administrator) would repeat the exercise we are performing here, with you manually running the find/grep command.
With that said, yes, we can direct the output of the failed validation test to a text file. We then have access to know immediately where the failure occurs. I updated the script to redirect a failed output to a text file and perform respective cleanup. The script was uploaded in GIT commit eeabba1c.
Please test that latest version against your profile.
Thanks for your patience and testing. :-)
Darrell
Darrell Anderson wrote:
The only output I see there (I guess the -e is a small bug?).
Hmm. Works fine here. Possibly a bashism? Is bash used on your system when running starttde? If not, then is the -e option supported in the shell you are using?
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.
That is the message I get indeed. I ran this command: find /home/julius/.trinity/ -name "*.desktop" -exec grep -l "KDE;" {} ;
But there was no output. Here is a screenshot of it: https://lh3.googleusercontent.com/--uMdK0xwgtU/UAxGk6mg6AI/AAAAAAAAA6Y/8splt...
Okay, so the problem is a *.desktop file. :-)
The reason there was no output whe you ran the find/grep command manually is we used the wrong text string for grep. Based upon the X dialog popup in the screen grab, the appropriate search would be this:
find /home/julius/.trinity -name "*.desktop" -exec grep -l "X-KDE" {} ;
The grep -l option will list the problematic file. Eliminate the -l option to view the problematic lines in that file. I'm curious to see what the failure might be.
Here is all the relevant output: julius@wijsvinger:~$ find /home/julius/.trinity -name "*.desktop" -exec grep -l "X-KDE" {} ; /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/history.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/remote.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/root.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/metabar.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/services.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/home.desktop /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/bookmarks.desktop julius@wijsvinger:~$ find /home/julius/.trinity -name "*.desktop" -exec grep "X-KDE" {} ; X-KDE-TreeModule=History X-KDE-SearchableTreeModule=true X-KDE-KonqSidebarModule=konqsidebar_tree X-KDE-TreeModule=Virtual X-KDE-RelURL=remote X-KDE-KonqSidebarModule=konqsidebar_tree X-KDE-TreeModule=Directory X-KDE-KonqSidebarModule=konqsidebar_tree X-KDE-KonqSidebarModule=konqsidebar_metabar X-KDE-TreeModule=Virtual X-KDE-RelURL=services X-KDE-KonqSidebarModule=konqsidebar_tree X-KDE-TreeModule=Directory X-KDE-KonqSidebarModule=konqsidebar_tree X-KDE-TreeModule=Bookmarks X-KDE-SearchableTreeModule=true X-KDE-KonqSidebarModule=konqsidebar_tree julius@wijsvinger:~$ ls -lh /home/julius/.trinity/share/apps/konqsidebartng/webbrowsing/entries/ totaal 60K -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
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).
I'll see if I can fetch the new script. I'm a bit surprised that the script immediately starts executing when I run it now. This doesn't really make it suitable for specific diagnosing or using it to update another user's profile. Could it just display some instructions on how it can be used when it's run without any parameters?
When the script is run the first time from within starttde, there are only the stdout (redirected to an xsession log when available) and X dialog messages. When the script is run a subsequent time, and the first execution was run successfully, the only way to run the script thereafter is manually from the command line. When a user tries this, the script detects the contents of kdeglobals and reports the script has been run previously and adds a note that to run the script multiple times requires using the "force" parameter.
With a failed execution, the script runs every time from within starttde. The last version I uploaded added an X dialog popup reflecting this problem and includes an "error code." The error code is nothing more than a shortcut method to identify which snippets in the script are causing failures. When that happens we (or an administrator) would repeat the exercise we are performing here, with you manually running the find/grep command.
With that said, yes, we can direct the output of the failed validation test to a text file. We then have access to know immediately where the failure occurs. I updated the script to redirect a failed output to a text file and perform respective cleanup. The script was uploaded in GIT commit eeabba1c.
Please test that latest version against your profile.
Alright, I'll look into it! Seems we're getting closer to a steady migration script :)
Julius
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
Hi,
Sorry for my late reply. I was very busy the past days.
Darrell Anderson wrote:
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.
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.
-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
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)?
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
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 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.
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. :-)
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.
Thanks for your patience. :-)
Darrell
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
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.
Darrell
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
-
Darrell Anderson -
Julius Schwartzenberg