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