<div dir="ltr"><div>Hello Karl, Thanks for your answer.<br></div><div><br></div><div>Yes, that does explain the behaviour. I didn't know that shell treated "../" and "./" paths this way. <br></div><div>I just checked and \input with TEXINPUTS have a consistent behaviour. </div><div><br></div><div>Cheers, Tohiko.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 9:40 PM Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tohiko - I admit I did not try to reproduce your problem (thanks for<br>
the careful report and scripts; much appreciated), because I saw this in<br>
your mail:<br>
<br>
    only when the path starts with `..` (or `.`).<br>
<br>
I made the decision when I wrote kpathsea that if a filename started<br>
with an explicit "." or "..", it would be treated as an absolute path<br>
(same as if it started with "/" or "C:" or whatever), and only looked up<br>
as-is, not along the search paths.  Normal shells do it that way, so it<br>
seemed like this was the most intuitive thing to do.<br>
<br>
I wouldn't claim that the entire TeX suite is 100% consistent in this<br>
regard, but I think that might explain the behavior you're seeing?<br>
--thanks, karl.<br>
</blockquote></div>