Hi!
Ralph Glasstetter wrote:
> Arghhh... I'm going nuts!!!
And for a very good reason, because...
[...]
>>Unless it's an older binary, or gets the line from somewhere else.
>
> Obviously the latter, since I've no older binary on my box... at least non
> with the name "dvbcut".
>
> BTW, revision 43 writes the same strange "old" line into dvbcut.sf.netrc...
> feel free to inspect/try the executable from my webpage.
I did. And guess what? It works correctly!
[...]
> It still remains a mystery what happens on my linux box...
Since the binary is obviously correct, my second guess must be true:
There's another config file hidden somewhere that Qt uses as a fallback.
According to the Qt documentation for class QSettings, there are several
possible locations:
> There is no universally accepted place for storing application settings
> under Unix. In the examples the settings file will be searched for in
> the following directories:
>
> 1. SYSCONF - the default value is INSTALL/etc/settings
Note that this may also be something like /etc/opt/qt3/settings,
according to the Linux Filesystem Hierarchy Standard. Or even
/etc/opt/kde3/settings.
> 2. /opt/MyCompany/share/etc
> 3. /opt/MyCompany/share/MyApplication/etc
MyCompany should translate to "dvbcut.sf.net" and MyApplication simply
is "dvbcut". Again, this may turn out to be something like
/etc/opt/dvbcut.sf.net/share/etc or similar.
> 4. $HOME/.qt
>
> When reading settings the files are searched in the order shown
> above, with later settings overriding earlier settings. Files for which the
> user doesn't have read permission are ignored. When saving settings
> QSettings works in the order shown above, writing to the first settings
> file for which the user has write permission. (INSTALL is the directory
> where Qt was installed. This can be modified by using the configure
> script's -prefix argument )
That is, if you ever used dvbcut with root privileges (e.g. inside su or
sudo), it may have written the settings to one of the system directories
instead because it suddenly had write permissions. Search and destroy
that file (all of them if there is more than one) and you should be okay
again. In case you can't find the file, try these lines:
strace -o log -e trace=access dvbcut
# quit dvbcut, and then
grep dvbcut log
That should show you where dvbcut looks for the file as well as where it
finds it (i.e. when access returns 0).
Stupid behavior, though. Qt should not write to the system directories
even if the application is permitted to do so. System config files are
supposed to provide defaults for *all* users. Besides the fact that root
should not use dvbcut at all for security reasons, his own preferences
should go to ~root/.qt, and nowhere else. But what did you expect from a
Troll(tm) company that lets their product write to the Windows registry
as well?
*sigh*
--
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DVBCUT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
