![](https://secure.gravatar.com/avatar/4e9e1d8d1a9e48815e89a0c42439fd82.jpg?s=120&d=mm&r=g)
Hello, \typefile does not output a file not in the current directory but available from a path defined by \usepath. It sounds like a bug since the file is actually found; if not, a message telling that the file does not exist would be printed. Example: \usepath[/path/to/my/file] \typefile{filebasename} Regards, BG
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
nico wrote:
Hello,
\typefile does not output a file not in the current directory but available from a path defined by \usepath. It sounds like a bug since the file is actually found; if not, a message telling that the file does not exist would be printed.
Example: \usepath[/path/to/my/file] \typefile{filebasename}
what version of context do you run? i though that i added support for that some time ago Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/4e9e1d8d1a9e48815e89a0c42439fd82.jpg?s=120&d=mm&r=g)
On Sun, 30 Apr 2006 12:33:20 +0200, Hans Hagen
nico wrote:
Hello,
\typefile does not output a file not in the current directory but available from a path defined by \usepath. It sounds like a bug since the file is actually found; if not, a message telling that the file does not exist would be printed.
Example: \usepath[/path/to/my/file] \typefile{filebasename}
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. Regards, BG
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
nico wrote:
On Sun, 30 Apr 2006 12:33:20 +0200, Hans Hagen
wrote: nico wrote:
Hello,
\typefile does not output a file not in the current directory but available from a path defined by \usepath. It sounds like a bug since the file is actually found; if not, a message telling that the file does not exist would be printed.
Example: \usepath[/path/to/my/file] \typefile{filebasename}
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 -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/4e9e1d8d1a9e48815e89a0c42439fd82.jpg?s=120&d=mm&r=g)
On Sun, 30 Apr 2006 15:22:49 +0200, Hans Hagen
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. Regards, BG
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
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 ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/4e9e1d8d1a9e48815e89a0c42439fd82.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/4e9e1d8d1a9e48815e89a0c42439fd82.jpg?s=120&d=mm&r=g)
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. it's
\makelocreadfilename{#3}%
that does the search
With the following patch it works: the \filepath found is used to expand the filename. \makelocreadfilename is still used, but i don't understand its role. \def\dodotypefile[#1][#2]#3% {\bgroup \let\currenttypingclass\??tp \edef\currenttyping{#1}% \typingparameter\c!before \doiflocfileelse{#3} \donetrue % sets \readfilename {\doifinputfileelse{#3} {\donetrue\def\readfilename{\pathplusfile{\filepath}{#3}}} % here the filename is absolute \donefalse}% \ifdone \startpacked % includes \bgroup \dosetuptypelinenumbering{#2}% \doifinset{\typingparameter\c!option}{\v!commands,\v!slanted,\v!normal} {\setuptyping[#1][\c!option=\v!none]}% \doif{\typingparameter\c!option}\v!color {\expandafter\aftersplitstring#3\at.\to\prettyidentifier \settypingparameter\c!option{\prettyidentifier}}% \initializetyping \startverbatimcolor % still use this macro, but applied to \readfilename instead of #3 \makelocreadfilename{\readfilename}% \doifundefinedelse{\currenttypingclass#3\v!global\c!start} ... Now it can wait a real fix :-) Regards, BG
participants (2)
-
Hans Hagen
-
nico