tags 358330 + fixed-upstream
stop
On 15.07.06 Karl Berry ([EMAIL PROTECTED]) wrote:
Hi Karl,
This next patch does the job correctly. An alternative, simpler,
patch follows below, which does not remove the empty path element.
I installed the first of your two alternative patches,
On Fri, Jul 14, 2006 at 06:59:17PM -0500, Karl Berry wrote:
Hi Julian and all,
This next patch does the job correctly. An alternative, simpler,
patch follows below, which does not remove the empty path element.
I installed the first of your two alternative patches, the one which
Hi Julian and all,
This next patch does the job correctly. An alternative, simpler,
patch follows below, which does not remove the empty path element.
I installed the first of your two alternative patches, the one which
does remove the empty path elements. Why not.
I also restored /.
On Mon, Mar 27, 2006 at 01:40:56PM -0600, Karl Berry wrote:
I think that the correct solution is to replace the final default else
with the conditional test:
} else if (elt[0] != 0) {
/* empty components can appear in TEXMFCNF; we skip over these */
Sounds
On Mon, Mar 27, 2006 at 01:40:56PM -0600, Karl Berry wrote:
I think that the correct solution is to replace the final default else
with the conditional test:
} else if (elt[0] != 0) {
/* empty components can appear in TEXMFCNF; we skip over these */
Sounds
Thomas Esser [EMAIL PROTECTED] wrote:
texmf.cnf, in the current directory are read. Or tried to read, the
user who reported this as http://bugs.debian.org/358330 has an
nfs-mounted homedir in which root has no right to read files, and always
gets error messages:
Vincent, what's the output of:
kpsewhich --expand-var='$TEXMFCNF'
and do you have the environment variable TEXMFCNF set?
On Mon, Mar 27, 2006 at 10:00:03AM +0200, Frank K??ster wrote:
Thomas Esser [EMAIL PROTECTED] wrote:
texmf.cnf, in the current directory are read. Or tried to read, the
Julian Gilbey wrote:
Vincent, what's the output of:
kpsewhich --expand-var='$TEXMFCNF'
and do you have the environment variable TEXMFCNF set?
I have no TEX.. variable set :
[EMAIL PROTECTED]:~$ sudo su
[EMAIL PROTECTED] danjean# export | grep TEX
And still the different behavior weather
On Mon, Mar 27, 2006 at 01:14:51PM +0200, Vincent Danjean wrote:
Julian Gilbey wrote:
Vincent, what's the output of:
kpsewhich --expand-var='$TEXMFCNF'
and do you have the environment variable TEXMFCNF set?
I have no TEX.. variable set :
[EMAIL PROTECTED]:~$ sudo su
[EMAIL PROTECTED]
Julian Gilbey [EMAIL PROTECTED] wrote:
So this means that on my system KPSE_DOT is not searched for cnf files,
but it seems to be searched for TEXMF trees? kpsewhere doesn't show the
local copy, either.
That's a bit weird. And what's it doing traversing the /home/frank
tree, anyway?
$ kpsewhich --expand-var='$TEXMFCNF'
{/usr/bin,/usr,/}{,{/share,}/texmf{-local,}/web2c}::/usr/share/texmf/web2c:/usr/share/texmf/web2c
$ kpsewhich --expand-braces='$TEXMFCNF'
[For readers of tex-k: there's a bizarre bug reported at
http://bugs.debian.org/358330 in which fmtutil-sys tries to read the
local user's directory, which it shouldn't. The bug log contains the
hunt for the source of this problem, and this is a proposed solution.]
On Mon, Mar 27, 2006 at
I think that the correct solution is to replace the final default else
with the conditional test:
} else if (elt[0] != 0) {
/* empty components can appear in TEXMFCNF; we skip over these */
Sounds reasonable to me. Thomas, Olaf?
Thanks Julian (and all).
karl
--
Sounds reasonable to me. Thomas, Olaf?
Ok for me.
Ha! All this reminds me to
TEXMF_CNF = $SELFAUTODIR:$SELFAUTOPARENT:/.$TETEXDIR
which I have had in teTeX-0.2.1:
[EMAIL PROTECTED]:/build/tetex-0.2/kpse-2.4/kpathsea ls -l texmf.cnf.in
-rw-r--r-- 1 te users 3007 1994-10-31 14:11
Someone did not like this /. and has removed it. Karl? Olaf? :-)
I don't remember doing so, although I may have in a fit of madness.
I can put it back.
I guess TETEXDIR is always specified as an absolute path? Or am I
missing something else?
Thanks,
Karl
--
To UNSUBSCRIBE, email to
I can put it back.
Yes, that would be good, thanks.
I guess TETEXDIR is always specified as an absolute path?
Yes.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
: ${KPSE_DOT=$thisdir}
export KPSE_DOT
The reason for me to implement KPSE_DOT in all kind of scripts (mktexpk,
fmtutil etc.) was to try to immitate a regular call of mf / tex as close
as possible. I.e. people might have a local hyphenation pattern file
which they could use via
tex -ini
Can somebody explain to me the reason for [KPSE_DOT]
I've forgotten, if I ever knew. Thomas?
I have a few observations, not especially related to the original report.
1) kpathsea/expand.c says (and implements):
/* If $KPSE_DOT is defined in the environment, prepend it to any relative
18 matches
Mail list logo
