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/8spl…
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