Re: texdoctk 0.5.2 beta3
On Wed, Feb 26, 2003 at 03:12:32AM +0100, Reinhard Kotucha wrote: > Does it mean that the save button will be removed? Sorry, a misunderstanding. I had written "the saved settings are not (again) stored in $HOME/.texdocrc ." where I wanted to write "the saved settings are now (again) stored in $HOME/.texdocrc ." :-( > Of course both files can be in different texmf trees and should be > looked up independently. Ok, sure. E.g. a texdocrc.defaults in a local texmf tree makes sense. So, I have two independend kpsewhich calls now. Thomas
Re: texdoctk 0.5.2 beta3
> "Thomas" == Thomas Esser <[EMAIL PROTECTED]> writes:
> texdocrc.defaults is written to $HOME when the options are
> saved. This is against Thomas R.'s intention and was introduced
> in TeX Live. I have fixed this in beta4
Does it mean that the save button will be removed?
> Maybe, an additional fix might be helpful:
> - my $database="$datadir/texdoctk.dat";
> + my $database=`kpsewhich --progname=texdoctk --format=${qq}other text
files${qq} texdoctk.dat`;
> This is to fix the situation where a locally installed older
> texdoctk in a local texmf tree had a texdocrc.defaults but no
> texdoctk.dat in the local tree (older versions of texdoctk have
> used different names for the database files).
> Comments on this change?
Of course both files can be in different texmf trees and should be
looked up independently.
Reinhard
--
Reinhard Kotucha Phone: +49-511-27060390
Marschnerstr. 25
D-30167 Hannover mailto:[EMAIL PROTECTED]
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
Re: texdoctk 0.5.2 beta3
> The path searched by kpsewhich contains "." as its first element, so
> $sysrc points to a file "texdocrc.defaults" in the current working
> directory instaed of the real system file.
>
> This is not bad in general, but obviously the value of $sysrc is used
> to find the database file as well.
texdocrc.defaults is written to $HOME when the options are saved. This
is against Thomas R.'s intention and was introduced in TeX Live. I have
fixed this in beta4 (Thomas R. has written to me that he has no time
to work on texdoctk at the moment): the saved settings are not (again)
stored in $HOME/.texdocrc .
Maybe, an additional fix might be helpful:
- my $database="$datadir/texdoctk.dat";
+ my $database=`kpsewhich --progname=texdoctk --format=${qq}other text files${qq}
texdoctk.dat`;
This is to fix the situation where a locally installed older texdoctk
in a local texmf tree had a texdocrc.defaults but no texdoctk.dat in
the local tree (older versions of texdoctk have used different names
for the database files).
Comments on this change?
Thomas
Re: texdoctk 0.5.2 beta3
Hi,
if texdoctk is called from the $HOME directory and there exists a file
"texdocrc.defaults" in this directory, then texdoctk fails with an
error message:
Couldn't open database ./texdoctk.dat.
There are two variables that describe locations of config files,
namely $sysrc and $myrc.
$sysrc is determined by running the command
kpsewhich --progname=texdoctk --format='other text files' texdocrc.defaults
The path searched by kpsewhich contains "." as its first element, so
$sysrc points to a file "texdocrc.defaults" in the current working
directory instaed of the real system file.
This is not bad in general, but obviously the value of $sysrc is used
to find the database file as well.
There are two solutions. The first one is to move to an existing
directory ("/", for example) where a "texdocrc.defaults" certainly
doesn't exist.
I tried "cd / && kpsewhich --progname=..." with success.
On Widows you could move to C:\ but probably L. User declares this to
his $HOME directory.
The second solution is to call the user config file "texdocrc"
instead of "texdocrc.defaults". In this case you avoid trouble with
different systems. Dvips looks for a file "$HOME/dvipsrc" and I think
that it is not a bad idea if texdoctk has a config file that looks
similar.
Regards,
Reinhard
--
Reinhard Kotucha Phone: +49-511-27060390
Marschnerstr. 25
D-30167 Hannover mailto:[EMAIL PROTECTED]
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
