genericmaillists posted on Sat, 31 Oct 2009 01:48:48 -0400 as excerpted:
> No, I could not get it to save anything other then probably the
> container, which did nothing. It would not save the configuration inside
> the option at all. Even doing a re-boot and trying again got the same
> results, the error.
Hmm... Do you have strace installed? Do you know how to use it? If not,
you can take a look at the manpage, but I'll often use it to find what
files a program is accessing or trying to access. It prints a ***LOT***
of output by default, probably thousands of lines for even a typical
short and simple startup and shutdown and app, without actually doing
anything, so one ***MUST*** learn how to filter the output, but once
that's learned, and with a bit of patience, strace can reveal all sorts
of stuff.
Of course, so could reading the source... if one's skilled enough in the
art to actually understand what one's reading, but for many of us,
learning to filter the strace output for a run is easier than poring thru
source not really knowing what one is looking at, for hours, hoping the
needle in the haystack will shine enough to pickout when we finally get
to it.
Anyway, to see what files a program is opening,
strace -eopen <program> <program's command-line parms>
Of course, run that in a konsole or other terminal window.
-eopen says to only report on system calls that attempt to open files.
Depending on the app and how it works, one might also need the -f, follow-
forks-also, option.
However, a typical X program will still spit out hundreds of lines of
attempted file-opens, icons, fonts, config-files, X-sockets, cursors,
multiple shared system libraries, all sorts of stuff, many items of which
it'll actually check several locations for by default, until it finds
where the file is actually located on your distribution. One thing
working with strace does is give you an *ENTIRELY* new appreciation for
just how much work your computer does when it runs a program, and a new
awe that it can actually do all that in the short time it normally
takes. Once one sees the output, it's not hard to imagine it taking
hours to start a single program, but it does it in seconds, often
fractions of a second if all the files are in-cache.
Anyway, the result is that even filtering to only file-opens is way too
much haystack to sift thru. That's where the pipe to grep comes in
handy. If you know the approximate location of the file access you're
looking for, you can grep for it. If not, then you grep -v (only show
lines NOT containing the grepped string), filtering out all the common
stuff, one thing at a time. So a line such as this isn't unusual, when
looking for a config file access:
strace -feopen <command and parms> 2>&1 | grep -v 'icon\|cursor\|lib\|
font'
That'd get you started. The 2>&1 redirects STDERR to STDOUT so it can be
grepped, as strace outputs to STDERR. You'd probably add more cases to
that regex OR expression as you found them.
In our case, however, the config files we're looking for are going to be
in one of two locations, either under /usr/share/ (assuming that's your
kde system configdir) or under ~/.kde/share/ (assuming that's your kde
user configdir). Thus, something simpler, like this, is a good way to
start:
strace -feopen kcmshell4 solid-actions 2>&1 | grep '/share/'
(kcmshell4 is what's used to launch individual kcontrol applets. You can
get a list using kcmshell4 --list. There really are some interesting
ones! A quick kcmshell4 --list | grep device gave me several
alternatives, solid-actions looked the most likely, and running it
confirmed it. We're using that here, to shorten the strace output that
would otherwise show up as it loaded the various things as you searched
for the device actions applet.)
Even with that filter, it gives me ~150 lines of output, here, but that's
at least a bit digestible, and you can run that into a second grep -v to
filter out irrelevant stuff (probably /locale/\|X11...) if you want. Or
if you aren't interested in the system config in /usr/share, only your
user config, change the grep /share/ to your home share dir, eliminating
all the /usr/share entries in one whack.
The object of all this is to find what config files it's actually writing
-- or attempting to write -- to. You can then check permissions
appropriately, maybe open them with a text editor and see if the format's
simple enough to manually configure doing a text-file edit, etc. Of
course, as I said, you can check the sources if you know how to read
them, but I was using this technique back on MS Windows (using a file
access reporting tool other than strace, of course) over a decade ago
(It's been nearly that long since I switched to Linux and freedomware)
for proprietary apps, and it works just as well on Linux for freedomware
apps. It really does work amazingly well; one just needs a bit of
patience as one figures out what grep regexs to use to cut the haystack
down to something manageable in which one can hope to find the needle
one's looking for! =:^) If I were really efficient, I'd setup a script
with all the normal filters (icons, fonts, etc) already included, so I
could just run the script, feeding it the app and parameters, and
filtering output further as necessary, but I haven't, yet.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
