Re: [urgent] update-fontlang new checks
On Mon, Oct 09, 2006 at 23:15 +0200, Norbert Preining wrote:
> As discussen in the IRC meeting today we want to have another check in
> user-mode of update-* scripts. Rational: Therespective file is normally
> generated in TEXMFVAR, which is in usermode normally .texmf-var. Now
> there could be the same file in TEXMFCONFIG, .texmf-config which will
> shadow the former one, the one in TEXMFVAR.
A reasonable goal.
> The first change defines an additional PATH_COMPONENT:
Looks good. SYSPATH_BASE is common to all three cases, so one could move
it outside. But I am not sure if it where better. I am sure, though,
that it is not important.
> NOTE NOTE NOTE: I believe this was also a bug in the current version: It
> which for update-language was wrong, as it put the language.dat into
> texmfvar/web2c/language.dat, and I don't believe it would be found
> there. So I changed this, too.
ACK, this is indeed a bug, which you are fixing here.
> @@ -409,7 +415,26 @@
> texmfvar=$(kpsewhich --expand-path '$TEXMFVAR')
> if ! echo "$texmfvar" | grep -e ':'; then
> - output_file="$texmfvar/web2c/$DEFAULT_OUTPUTFILE_BASENAME"
> + output_file="$texmfvar/$PATH_COMPONENT/$DEFAULT_OUTPUTFILE_BASENAME"
> + # it could be that there is a DEFAULT_OUTPUTFILE_BASENAME file
> + # in TEXMFCONFIG, which would be found instead of the
> + # output_file. So we check for this and give a warning in case
> + # the created file would be shadowed.
> + OLDIFS="$IFS"
> + IFS=:
> + for d in "$texmfconfig"; do
I am not sure this is the ideal place for this check, since it will only
be made when TEXMFVAR points to a single directory. This is the most
likely case, though, and if it is not the case, the user has to specify
output_file directly. One could assume an 'expert user' in this case.
> + if [ -r "$d/$PATH_COMPONENT/$DEFAULT_OUTPUTFILE_BASENAME" ]; then
> + printf "\
> +You are about to generate the file
> + $output_file
> +but at the same time you have a file
> + $d/$PATH_COMPONENT/$DEFAULT_OUTPUTFILE_BASENAME
> +which will shadow the former one. We will continue generating the first
> +file, but to make TeX and friends find it, you have to remove the later one.\n"
The "former ... later" construct might be a bit difficult for some
people. Offhand I don't know a better way to say this, though.
> + fi
> + break
> + done
> + IFS="$OLDIFS"
> # We don't know what to do in this case, therefore: do nothing unless
> # the output file is specified with the correponding option.
Of course, it would be cleaner to have common code for the various
sanity checks. But that isn't implemented that easily.
Overall I don't see any showstoppers.