On Sun, 30 Apr 2006 18:59:53 +0200, Hans Hagen
nico wrote:
On Sun, 30 Apr 2006 15:22:49 +0200, Hans Hagen
wrote: what version of context do you run? i though that i added support for that some time ago
Version 2006.04.27.
\dodotypefile checks where the file is, but a following call to \makelocreadfilename seems to set improperly \readfilename, but I'm not sure to understand correctly the code.
\tracefilestrue
Hm, verbatim seems not using the file interface: there's no trace about file found or not related to typefile. Another thing I did is to patch \processfileverbatim to trace what is actually the file used:
\def\processfileverbatim#1% {\par \bgroup \writestatus{jo}{file=#1} ...
And doing:
\typefile{list1.tex} % file in the current directory (ok) \typefile{test-001.tex} % file in the \usepath directory (nok) \typefile{joke} % file that does not exist (ok, an error is printed) \typefile{pos2.tex} % again a local existing file (ok)
Gives the traces:
systems : begin file typefile at line 79 jo : file=list1.tex systems : searching for pdfr-ec on tex path systems : pdfr-ec located (/usr/local/share/texmf-local/tex/context/base/pdfr-ec.tex) jo : file=test-001.tex verbatim : file joke does not exist jo : file=pos2.tex
So, the actual file path is not used, but it is the argument passed that is always used.
it's
\makelocreadfilename{#3}%
that does the search
Really? As far as I understand the code, it sets \readfilename and \locreadfilename in a clean way, and that's all: \def\makelocreadfilename#1% {\sanitizefilename#1\to\readfilename \checkfilename\readfilename \ifcase\kindoffile \edef\locreadfilename{\pathplusfile\f!currentpath{#1}}% \fi} Anyway, if it's that call that should expand the filename, it does not work. In \dodotypefile the search is done previously by a call to \doifinputfileelse that sets \filepath (set again to \readfilename but I don't know why), but this result is not used since \readfilename is re-set to #3 by \makelocreadfilename. But you know this far better than I :-) Regards, BG