Relative paths with windows path separator does not work in TeXlive2019.
kirillbalunov at gmail.com
Fri Jul 26 10:51:28 CEST 2019
Philip thank you! I agree with your comments about ambiguity, also `TeX
--help` has a comment about starting with a `backslash`, I'm ok with it.
But there is a tiny little dot (full stop) in the beginning of my examples,
and I expect it should be enough to dispel ambiguity -> I worte `TeX
and not `TeX \some\file.tex` without a dot, does this make sense to you?
with kind regards,
пт, 26 июл. 2019 г. в 11:19, Taylor, P <P.Taylor at rhul.ac.uk>:
> Kirill Balunov wrote:
> Maybe I incorrectly described in what, in my opinion, TeX Live can
> better. I fully ok with the removal of 8.3 names support, their time
> has passed.
> But as for the directory separator, I would like to TeXLive (on Windows)
> to be as agnostic as possible, for two reasons:
> 1. It works in some parts, but not in the others.
> 2. No error is produced.
> Concerning the 1. as I showed in the example it is ok to use both
> -output-directory=".\Tex\local" and -output-directory="./Tex/local", but
> this does not work for input files ( this is obviously perceived as an
> existing possibility, but to some extent not coordinated in various places).
> Maybe I completely do not understand what difficulties are on the way. If
> so I would like to know what they are.
> Why I am so concerned :) because many cross-platform libraries and
> utilities that work with paths (directories) use platform dependent
> directory separators (and usually the user has no control over this). And
> this miss in the TeXLive functionality in some parts, breaks their lovely
> attempts. Of course it is not difficult at the end to replace every "\"
> with "/", but it looks pretty crazy to do this for program running on
> Windows. And of course it is a very hard to find bug, because no error is
> The problem is simply that TeX's escape character is the same as MS-DOS's
> path-element separator (a backslash). Once that is accepted, it is clear
> that TeX cannot of itself unambiguously parse (e.g.,) "TeX
> \string\filename.extension. It cannot know whether "string" is a command
> or a path element. Therefore a rule has to be implemented, and that rule
> is "TeX commands take precedence" — wherever "\string" occurs in a context
> where it could represent a command and could also represent a path element,
> it will invariably be parsed as a command.
> Philip Taylor
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tex-live