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/8spltYcrKjI/s731/r14-xdg-update.png > > 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
