Different file opened by openin (was: between 2017 and 2018)












3














Short version:



It seems that some trivial behavior of file opening (openin) changed between TeX Live 2017 and 2018 differs between environment. Only Overleaf one behaves differently. I did not see any notice about that, but why?





Consider the following code:



openin1 read1 to X closein1 showX


Normally openin should be followed by a file, but here that is omitted. TeX/e-TeX/e-(u)pTeX/XeTeX/LuaTeX of Overleaf (TL2017) showed par, but my local installation (TL2018) and Cloud LaTeX (TL2017), Japanese TeX on Web (TL2016; only e-pTeX available) shows nothing (empty).



Similar difference with e-TeX:



openin1 readline1 toXshowXreadline1 toXshowXreadline1 toXshowXclosein1 bye


e-TeX of Overleaf returned only ^^M and stopped, but that of my local installation shows:



> X=macro:
->%%^^M.
<*> openin1 readline1 toXshowX
readline1 toXshowXreadline1 toXsho...

?
> X=macro:
->%% This is file `.tex',^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
readline1 toXshowXclo...

?
> X=macro:
->%% generated with the docstrip utility.^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
closein1 bye
?
No pages of output.


The followings are my guess from these behavior:




  • ??? was read in Overleaf,


  • tools/.tex is being read in my local installation, Cloud LaTeX


I don't think this is a problem; just for curiosity.










share|improve this question




















  • 1




    I can't reproduce the issue.
    – egreg
    Dec 28 '18 at 14:28










  • Hmm, I tested on both Linux and Mac.
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:30










  • @egreg Which behavior you get?
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:31






  • 1




    I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
    – jfbu
    Dec 28 '18 at 14:32






  • 1




    Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
    – ShreevatsaR
    Dec 29 '18 at 1:40


















3














Short version:



It seems that some trivial behavior of file opening (openin) changed between TeX Live 2017 and 2018 differs between environment. Only Overleaf one behaves differently. I did not see any notice about that, but why?





Consider the following code:



openin1 read1 to X closein1 showX


Normally openin should be followed by a file, but here that is omitted. TeX/e-TeX/e-(u)pTeX/XeTeX/LuaTeX of Overleaf (TL2017) showed par, but my local installation (TL2018) and Cloud LaTeX (TL2017), Japanese TeX on Web (TL2016; only e-pTeX available) shows nothing (empty).



Similar difference with e-TeX:



openin1 readline1 toXshowXreadline1 toXshowXreadline1 toXshowXclosein1 bye


e-TeX of Overleaf returned only ^^M and stopped, but that of my local installation shows:



> X=macro:
->%%^^M.
<*> openin1 readline1 toXshowX
readline1 toXshowXreadline1 toXsho...

?
> X=macro:
->%% This is file `.tex',^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
readline1 toXshowXclo...

?
> X=macro:
->%% generated with the docstrip utility.^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
closein1 bye
?
No pages of output.


The followings are my guess from these behavior:




  • ??? was read in Overleaf,


  • tools/.tex is being read in my local installation, Cloud LaTeX


I don't think this is a problem; just for curiosity.










share|improve this question




















  • 1




    I can't reproduce the issue.
    – egreg
    Dec 28 '18 at 14:28










  • Hmm, I tested on both Linux and Mac.
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:30










  • @egreg Which behavior you get?
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:31






  • 1




    I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
    – jfbu
    Dec 28 '18 at 14:32






  • 1




    Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
    – ShreevatsaR
    Dec 29 '18 at 1:40
















3












3








3


1





Short version:



It seems that some trivial behavior of file opening (openin) changed between TeX Live 2017 and 2018 differs between environment. Only Overleaf one behaves differently. I did not see any notice about that, but why?





Consider the following code:



openin1 read1 to X closein1 showX


Normally openin should be followed by a file, but here that is omitted. TeX/e-TeX/e-(u)pTeX/XeTeX/LuaTeX of Overleaf (TL2017) showed par, but my local installation (TL2018) and Cloud LaTeX (TL2017), Japanese TeX on Web (TL2016; only e-pTeX available) shows nothing (empty).



Similar difference with e-TeX:



openin1 readline1 toXshowXreadline1 toXshowXreadline1 toXshowXclosein1 bye


e-TeX of Overleaf returned only ^^M and stopped, but that of my local installation shows:



> X=macro:
->%%^^M.
<*> openin1 readline1 toXshowX
readline1 toXshowXreadline1 toXsho...

?
> X=macro:
->%% This is file `.tex',^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
readline1 toXshowXclo...

?
> X=macro:
->%% generated with the docstrip utility.^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
closein1 bye
?
No pages of output.


The followings are my guess from these behavior:




  • ??? was read in Overleaf,


  • tools/.tex is being read in my local installation, Cloud LaTeX


I don't think this is a problem; just for curiosity.










share|improve this question















Short version:



It seems that some trivial behavior of file opening (openin) changed between TeX Live 2017 and 2018 differs between environment. Only Overleaf one behaves differently. I did not see any notice about that, but why?





Consider the following code:



openin1 read1 to X closein1 showX


Normally openin should be followed by a file, but here that is omitted. TeX/e-TeX/e-(u)pTeX/XeTeX/LuaTeX of Overleaf (TL2017) showed par, but my local installation (TL2018) and Cloud LaTeX (TL2017), Japanese TeX on Web (TL2016; only e-pTeX available) shows nothing (empty).



Similar difference with e-TeX:



openin1 readline1 toXshowXreadline1 toXshowXreadline1 toXshowXclosein1 bye


e-TeX of Overleaf returned only ^^M and stopped, but that of my local installation shows:



> X=macro:
->%%^^M.
<*> openin1 readline1 toXshowX
readline1 toXshowXreadline1 toXsho...

?
> X=macro:
->%% This is file `.tex',^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
readline1 toXshowXclo...

?
> X=macro:
->%% generated with the docstrip utility.^^M.
<*> ...readline1 toXshowXreadline1 toXshowX
closein1 bye
?
No pages of output.


The followings are my guess from these behavior:




  • ??? was read in Overleaf,


  • tools/.tex is being read in my local installation, Cloud LaTeX


I don't think this is a problem; just for curiosity.







tex-core filesystem-access primitives






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 29 '18 at 4:03

























asked Dec 28 '18 at 14:08









Hironobu YAMASHITA

48437




48437








  • 1




    I can't reproduce the issue.
    – egreg
    Dec 28 '18 at 14:28










  • Hmm, I tested on both Linux and Mac.
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:30










  • @egreg Which behavior you get?
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:31






  • 1




    I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
    – jfbu
    Dec 28 '18 at 14:32






  • 1




    Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
    – ShreevatsaR
    Dec 29 '18 at 1:40
















  • 1




    I can't reproduce the issue.
    – egreg
    Dec 28 '18 at 14:28










  • Hmm, I tested on both Linux and Mac.
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:30










  • @egreg Which behavior you get?
    – Hironobu YAMASHITA
    Dec 28 '18 at 14:31






  • 1




    I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
    – jfbu
    Dec 28 '18 at 14:32






  • 1




    Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
    – ShreevatsaR
    Dec 29 '18 at 1:40










1




1




I can't reproduce the issue.
– egreg
Dec 28 '18 at 14:28




I can't reproduce the issue.
– egreg
Dec 28 '18 at 14:28












Hmm, I tested on both Linux and Mac.
– Hironobu YAMASHITA
Dec 28 '18 at 14:30




Hmm, I tested on both Linux and Mac.
– Hironobu YAMASHITA
Dec 28 '18 at 14:30












@egreg Which behavior you get?
– Hironobu YAMASHITA
Dec 28 '18 at 14:31




@egreg Which behavior you get?
– Hironobu YAMASHITA
Dec 28 '18 at 14:31




1




1




I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
– jfbu
Dec 28 '18 at 14:32




I can't reproduce difference with etex with TL2016, 2017 (MacPorts binaries), and TL2018 (self-compiled binaries). They all behave as in your question.
– jfbu
Dec 28 '18 at 14:32




1




1




Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
– ShreevatsaR
Dec 29 '18 at 1:40






Overleaf runs with nonstopmode or batchmode, as if you try openin3="nonexistent.tex" read3 to X closein3 you get an error about cannot read from terminal in nonstop modes (and if you try to force it with errorstopmode, you get "End of file on the terminal!"). So the explanation cannot be that TeX is reading from the terminal. And yet openin1=".tex" read1 to X closein1 sets X to macro:->; it's only openin2 read2 to X closein2 that sets X to par... so if it's not reading from .tex and it's not reading from the terminal, where is it reading from?
– ShreevatsaR
Dec 29 '18 at 1:40












1 Answer
1






active

oldest

votes


















2














A few observations:




  • As of now, it appears that the atypical behaviour can be reproduced only on Overleaf, though an earlier version of the question mentioned the OP's observations on TL 2017 and on Japanese TeX on Web.


  • On Overleaf, this behaviour (where X gets set to par) can be reproduced not only with openin1 read1 to X (as in the question) but even with openin1= read1 to X and openin1="" read1 to X, but not with openin1=".tex" read1 to X (in which case X gets set to the empty macro, same as on other environments). In fact, with verbatiminput{.tex} (compiling with LaTeX and usepackage{verbatim}), one can see that even on Overleaf, the same .tex file is present, which we see loaded on other environments (texmf-dist/tex/latex/tools/.tex). (This is interesting, that reading from "" is not the same as reading from ".tex".) So with that explanation ruled out, let's stick to this openin1="" read1 to X form as it's perhaps most clear.


  • Sometimes read tries to read from the terminal, so this is another potential explanation. But if we try openin1="nonexistent.tex" read1 to X on Overleaf, we get a message from TeX about “cannot read from terminal in nonstop modes”, suggesting that TeX is being run with batchmode or nonstopmode. Even if we try to force the issue by first doing errorstopmode in our file, we get “End of file on the terminal!”. So this explanation is ruled out as well, which only deepens the mystery: if TeX is not reading from the file .tex and it's not reading from the terminal, where is it reading from?



Based on these observations, we can debug as follows: create a latexmkrc file containing



$latex = 'tex -recorder %O %S';


to record this, and prepare the following input file:



openin 1=".tex" 
read 1 to X
message{... With full filename, meaningX ...}
closein 1

openin 2=""
read 2 to X
message{... With blank filename, meaningX ...}
closein 2

openin 3=".tex"
read 3 to X
message{... With full filename, meaningX ...}
closein 3

obeylines
input jobname.fls
bye


(3 is the same as 1, just repeated to make the ordering clear). The log file contains:



This is TeX, Version 3.14159265 (TeX Live 2017) (preloaded format=tex 2017.7.12)  29 DEC 2018 10:20
**main.tex
(/compile/main.tex ... With full filename, macro:->... ... With blank filename,
macro:->par ... ... With full filename, macro:->... (/compile/output.fls) [1]
)
Output written on /compile/output.dvi (1 page, 716 bytes).


which illustrates the oddity, but even more interesting is the typeset output:



PWD /compile
INPUT /usr/local/texlive/2017/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-dist/web2c/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-var/web2c/tex/tex.fmt
INPUT /compile/main.tex
OUTPUT /compile/output.log
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/output.fls


-- note the INPUT /compile/ between the two occurrences of INPUTing .tex.



This seems to answer the mystery somewhat, while raising new ones: why does TeX (on Overleaf, and when given an empty filename) input (what appears to be) the directory containing the input file? (And what does it even mean to input a directory / why is the effect the same as reading an empty file?)



Unfortunately this is all very much in the system-dependent parts of TeX (i.e. in this case it's entirely internal to the kpathsea library), so to debug further without being able to reproduce locally seems hard. (Perhaps it has something do with chroot or some sort of sandboxing that Overleaf does.) I'll note though that there was a kpathsea commit on 2017-11-03 (so wasn't part of TL2017) that has something to do with empty filenames. Perhaps it's related.






share|improve this answer





















  • Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
    – Hironobu YAMASHITA
    Dec 29 '18 at 13:58










  • @HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
    – ShreevatsaR
    Dec 29 '18 at 20:07











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f467666%2fdifferent-file-opened-by-openin-was-between-2017-and-2018%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














A few observations:




  • As of now, it appears that the atypical behaviour can be reproduced only on Overleaf, though an earlier version of the question mentioned the OP's observations on TL 2017 and on Japanese TeX on Web.


  • On Overleaf, this behaviour (where X gets set to par) can be reproduced not only with openin1 read1 to X (as in the question) but even with openin1= read1 to X and openin1="" read1 to X, but not with openin1=".tex" read1 to X (in which case X gets set to the empty macro, same as on other environments). In fact, with verbatiminput{.tex} (compiling with LaTeX and usepackage{verbatim}), one can see that even on Overleaf, the same .tex file is present, which we see loaded on other environments (texmf-dist/tex/latex/tools/.tex). (This is interesting, that reading from "" is not the same as reading from ".tex".) So with that explanation ruled out, let's stick to this openin1="" read1 to X form as it's perhaps most clear.


  • Sometimes read tries to read from the terminal, so this is another potential explanation. But if we try openin1="nonexistent.tex" read1 to X on Overleaf, we get a message from TeX about “cannot read from terminal in nonstop modes”, suggesting that TeX is being run with batchmode or nonstopmode. Even if we try to force the issue by first doing errorstopmode in our file, we get “End of file on the terminal!”. So this explanation is ruled out as well, which only deepens the mystery: if TeX is not reading from the file .tex and it's not reading from the terminal, where is it reading from?



Based on these observations, we can debug as follows: create a latexmkrc file containing



$latex = 'tex -recorder %O %S';


to record this, and prepare the following input file:



openin 1=".tex" 
read 1 to X
message{... With full filename, meaningX ...}
closein 1

openin 2=""
read 2 to X
message{... With blank filename, meaningX ...}
closein 2

openin 3=".tex"
read 3 to X
message{... With full filename, meaningX ...}
closein 3

obeylines
input jobname.fls
bye


(3 is the same as 1, just repeated to make the ordering clear). The log file contains:



This is TeX, Version 3.14159265 (TeX Live 2017) (preloaded format=tex 2017.7.12)  29 DEC 2018 10:20
**main.tex
(/compile/main.tex ... With full filename, macro:->... ... With blank filename,
macro:->par ... ... With full filename, macro:->... (/compile/output.fls) [1]
)
Output written on /compile/output.dvi (1 page, 716 bytes).


which illustrates the oddity, but even more interesting is the typeset output:



PWD /compile
INPUT /usr/local/texlive/2017/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-dist/web2c/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-var/web2c/tex/tex.fmt
INPUT /compile/main.tex
OUTPUT /compile/output.log
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/output.fls


-- note the INPUT /compile/ between the two occurrences of INPUTing .tex.



This seems to answer the mystery somewhat, while raising new ones: why does TeX (on Overleaf, and when given an empty filename) input (what appears to be) the directory containing the input file? (And what does it even mean to input a directory / why is the effect the same as reading an empty file?)



Unfortunately this is all very much in the system-dependent parts of TeX (i.e. in this case it's entirely internal to the kpathsea library), so to debug further without being able to reproduce locally seems hard. (Perhaps it has something do with chroot or some sort of sandboxing that Overleaf does.) I'll note though that there was a kpathsea commit on 2017-11-03 (so wasn't part of TL2017) that has something to do with empty filenames. Perhaps it's related.






share|improve this answer





















  • Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
    – Hironobu YAMASHITA
    Dec 29 '18 at 13:58










  • @HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
    – ShreevatsaR
    Dec 29 '18 at 20:07
















2














A few observations:




  • As of now, it appears that the atypical behaviour can be reproduced only on Overleaf, though an earlier version of the question mentioned the OP's observations on TL 2017 and on Japanese TeX on Web.


  • On Overleaf, this behaviour (where X gets set to par) can be reproduced not only with openin1 read1 to X (as in the question) but even with openin1= read1 to X and openin1="" read1 to X, but not with openin1=".tex" read1 to X (in which case X gets set to the empty macro, same as on other environments). In fact, with verbatiminput{.tex} (compiling with LaTeX and usepackage{verbatim}), one can see that even on Overleaf, the same .tex file is present, which we see loaded on other environments (texmf-dist/tex/latex/tools/.tex). (This is interesting, that reading from "" is not the same as reading from ".tex".) So with that explanation ruled out, let's stick to this openin1="" read1 to X form as it's perhaps most clear.


  • Sometimes read tries to read from the terminal, so this is another potential explanation. But if we try openin1="nonexistent.tex" read1 to X on Overleaf, we get a message from TeX about “cannot read from terminal in nonstop modes”, suggesting that TeX is being run with batchmode or nonstopmode. Even if we try to force the issue by first doing errorstopmode in our file, we get “End of file on the terminal!”. So this explanation is ruled out as well, which only deepens the mystery: if TeX is not reading from the file .tex and it's not reading from the terminal, where is it reading from?



Based on these observations, we can debug as follows: create a latexmkrc file containing



$latex = 'tex -recorder %O %S';


to record this, and prepare the following input file:



openin 1=".tex" 
read 1 to X
message{... With full filename, meaningX ...}
closein 1

openin 2=""
read 2 to X
message{... With blank filename, meaningX ...}
closein 2

openin 3=".tex"
read 3 to X
message{... With full filename, meaningX ...}
closein 3

obeylines
input jobname.fls
bye


(3 is the same as 1, just repeated to make the ordering clear). The log file contains:



This is TeX, Version 3.14159265 (TeX Live 2017) (preloaded format=tex 2017.7.12)  29 DEC 2018 10:20
**main.tex
(/compile/main.tex ... With full filename, macro:->... ... With blank filename,
macro:->par ... ... With full filename, macro:->... (/compile/output.fls) [1]
)
Output written on /compile/output.dvi (1 page, 716 bytes).


which illustrates the oddity, but even more interesting is the typeset output:



PWD /compile
INPUT /usr/local/texlive/2017/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-dist/web2c/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-var/web2c/tex/tex.fmt
INPUT /compile/main.tex
OUTPUT /compile/output.log
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/output.fls


-- note the INPUT /compile/ between the two occurrences of INPUTing .tex.



This seems to answer the mystery somewhat, while raising new ones: why does TeX (on Overleaf, and when given an empty filename) input (what appears to be) the directory containing the input file? (And what does it even mean to input a directory / why is the effect the same as reading an empty file?)



Unfortunately this is all very much in the system-dependent parts of TeX (i.e. in this case it's entirely internal to the kpathsea library), so to debug further without being able to reproduce locally seems hard. (Perhaps it has something do with chroot or some sort of sandboxing that Overleaf does.) I'll note though that there was a kpathsea commit on 2017-11-03 (so wasn't part of TL2017) that has something to do with empty filenames. Perhaps it's related.






share|improve this answer





















  • Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
    – Hironobu YAMASHITA
    Dec 29 '18 at 13:58










  • @HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
    – ShreevatsaR
    Dec 29 '18 at 20:07














2












2








2






A few observations:




  • As of now, it appears that the atypical behaviour can be reproduced only on Overleaf, though an earlier version of the question mentioned the OP's observations on TL 2017 and on Japanese TeX on Web.


  • On Overleaf, this behaviour (where X gets set to par) can be reproduced not only with openin1 read1 to X (as in the question) but even with openin1= read1 to X and openin1="" read1 to X, but not with openin1=".tex" read1 to X (in which case X gets set to the empty macro, same as on other environments). In fact, with verbatiminput{.tex} (compiling with LaTeX and usepackage{verbatim}), one can see that even on Overleaf, the same .tex file is present, which we see loaded on other environments (texmf-dist/tex/latex/tools/.tex). (This is interesting, that reading from "" is not the same as reading from ".tex".) So with that explanation ruled out, let's stick to this openin1="" read1 to X form as it's perhaps most clear.


  • Sometimes read tries to read from the terminal, so this is another potential explanation. But if we try openin1="nonexistent.tex" read1 to X on Overleaf, we get a message from TeX about “cannot read from terminal in nonstop modes”, suggesting that TeX is being run with batchmode or nonstopmode. Even if we try to force the issue by first doing errorstopmode in our file, we get “End of file on the terminal!”. So this explanation is ruled out as well, which only deepens the mystery: if TeX is not reading from the file .tex and it's not reading from the terminal, where is it reading from?



Based on these observations, we can debug as follows: create a latexmkrc file containing



$latex = 'tex -recorder %O %S';


to record this, and prepare the following input file:



openin 1=".tex" 
read 1 to X
message{... With full filename, meaningX ...}
closein 1

openin 2=""
read 2 to X
message{... With blank filename, meaningX ...}
closein 2

openin 3=".tex"
read 3 to X
message{... With full filename, meaningX ...}
closein 3

obeylines
input jobname.fls
bye


(3 is the same as 1, just repeated to make the ordering clear). The log file contains:



This is TeX, Version 3.14159265 (TeX Live 2017) (preloaded format=tex 2017.7.12)  29 DEC 2018 10:20
**main.tex
(/compile/main.tex ... With full filename, macro:->... ... With blank filename,
macro:->par ... ... With full filename, macro:->... (/compile/output.fls) [1]
)
Output written on /compile/output.dvi (1 page, 716 bytes).


which illustrates the oddity, but even more interesting is the typeset output:



PWD /compile
INPUT /usr/local/texlive/2017/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-dist/web2c/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-var/web2c/tex/tex.fmt
INPUT /compile/main.tex
OUTPUT /compile/output.log
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/output.fls


-- note the INPUT /compile/ between the two occurrences of INPUTing .tex.



This seems to answer the mystery somewhat, while raising new ones: why does TeX (on Overleaf, and when given an empty filename) input (what appears to be) the directory containing the input file? (And what does it even mean to input a directory / why is the effect the same as reading an empty file?)



Unfortunately this is all very much in the system-dependent parts of TeX (i.e. in this case it's entirely internal to the kpathsea library), so to debug further without being able to reproduce locally seems hard. (Perhaps it has something do with chroot or some sort of sandboxing that Overleaf does.) I'll note though that there was a kpathsea commit on 2017-11-03 (so wasn't part of TL2017) that has something to do with empty filenames. Perhaps it's related.






share|improve this answer












A few observations:




  • As of now, it appears that the atypical behaviour can be reproduced only on Overleaf, though an earlier version of the question mentioned the OP's observations on TL 2017 and on Japanese TeX on Web.


  • On Overleaf, this behaviour (where X gets set to par) can be reproduced not only with openin1 read1 to X (as in the question) but even with openin1= read1 to X and openin1="" read1 to X, but not with openin1=".tex" read1 to X (in which case X gets set to the empty macro, same as on other environments). In fact, with verbatiminput{.tex} (compiling with LaTeX and usepackage{verbatim}), one can see that even on Overleaf, the same .tex file is present, which we see loaded on other environments (texmf-dist/tex/latex/tools/.tex). (This is interesting, that reading from "" is not the same as reading from ".tex".) So with that explanation ruled out, let's stick to this openin1="" read1 to X form as it's perhaps most clear.


  • Sometimes read tries to read from the terminal, so this is another potential explanation. But if we try openin1="nonexistent.tex" read1 to X on Overleaf, we get a message from TeX about “cannot read from terminal in nonstop modes”, suggesting that TeX is being run with batchmode or nonstopmode. Even if we try to force the issue by first doing errorstopmode in our file, we get “End of file on the terminal!”. So this explanation is ruled out as well, which only deepens the mystery: if TeX is not reading from the file .tex and it's not reading from the terminal, where is it reading from?



Based on these observations, we can debug as follows: create a latexmkrc file containing



$latex = 'tex -recorder %O %S';


to record this, and prepare the following input file:



openin 1=".tex" 
read 1 to X
message{... With full filename, meaningX ...}
closein 1

openin 2=""
read 2 to X
message{... With blank filename, meaningX ...}
closein 2

openin 3=".tex"
read 3 to X
message{... With full filename, meaningX ...}
closein 3

obeylines
input jobname.fls
bye


(3 is the same as 1, just repeated to make the ordering clear). The log file contains:



This is TeX, Version 3.14159265 (TeX Live 2017) (preloaded format=tex 2017.7.12)  29 DEC 2018 10:20
**main.tex
(/compile/main.tex ... With full filename, macro:->... ... With blank filename,
macro:->par ... ... With full filename, macro:->... (/compile/output.fls) [1]
)
Output written on /compile/output.dvi (1 page, 716 bytes).


which illustrates the oddity, but even more interesting is the typeset output:



PWD /compile
INPUT /usr/local/texlive/2017/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-dist/web2c/texmf.cnf
INPUT /usr/local/texlive/2017/texmf-var/web2c/tex/tex.fmt
INPUT /compile/main.tex
OUTPUT /compile/output.log
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/
INPUT /usr/local/texlive/2017/texmf-dist/tex/latex/tools/.tex
INPUT /compile/output.fls


-- note the INPUT /compile/ between the two occurrences of INPUTing .tex.



This seems to answer the mystery somewhat, while raising new ones: why does TeX (on Overleaf, and when given an empty filename) input (what appears to be) the directory containing the input file? (And what does it even mean to input a directory / why is the effect the same as reading an empty file?)



Unfortunately this is all very much in the system-dependent parts of TeX (i.e. in this case it's entirely internal to the kpathsea library), so to debug further without being able to reproduce locally seems hard. (Perhaps it has something do with chroot or some sort of sandboxing that Overleaf does.) I'll note though that there was a kpathsea commit on 2017-11-03 (so wasn't part of TL2017) that has something to do with empty filenames. Perhaps it's related.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 29 '18 at 10:57









ShreevatsaR

27.2k87198




27.2k87198












  • Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
    – Hironobu YAMASHITA
    Dec 29 '18 at 13:58










  • @HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
    – ShreevatsaR
    Dec 29 '18 at 20:07


















  • Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
    – Hironobu YAMASHITA
    Dec 29 '18 at 13:58










  • @HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
    – ShreevatsaR
    Dec 29 '18 at 20:07
















Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
– Hironobu YAMASHITA
Dec 29 '18 at 13:58




Thanks, it never occurred to me that the directory being read! For now we cannot reproduce the issue locally, I take this answer.
– Hironobu YAMASHITA
Dec 29 '18 at 13:58












@HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
– ShreevatsaR
Dec 29 '18 at 20:07




@HironobuYAMASHITA But I do not find it possible to read a directory, in my local TeX... may be something interesting worth asking the kpathsea people (texlive mailing list?)
– ShreevatsaR
Dec 29 '18 at 20:07


















draft saved

draft discarded




















































Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f467666%2fdifferent-file-opened-by-openin-was-between-2017-and-2018%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924

How to change which sound is reproduced for terminal bell?

Can I use Tabulator js library in my java Spring + Thymeleaf project?