Путь к файлу Windows

[arctium]

Попробовал в LaTeX под Windows пользоваться пакетом import, чтобы подключать файлы из других папок. Столкнулся с идиотской проблемой. Имена папок разделяются в Windows через "\" backslash. И последний слэш в пути к файлу убивает закрывающую фигурную скобку. TeX ее не видит, думает это просто один символ в тексте \}, и выдает ошибку, естественно.
Вставить пробел нельзя, путь должен заканчиваться именно на \.
\import{C:\MyDocuments\...\MyBook\Chapter1\} последние два символа склеиваются, и скобки нет для компилятора.
Все примеры в описании пакета из Unix, а там слэши в другую сторону, все в порядке.

Кто-нибудь знает, как с этим быть?

[venco]

В Виндах не обязательно использовать обратный слеш, прямой тоже работает. Некоторые программы, правда, прямой слеш трактуют как специальные аргументы командной строки, но внутри в названиях файлов оба слеша взаимозаменяемы.

[Red_Herring]

Попробуйте 1) не ставить последней бэкслэш 2) Использовать Unix, а не Windows path (т.е. слэши, а не бэкслэши).

[Vince Diesel]

Не пройдет в конце \backslash поставить?

[EtCetera]

Голосую за прямые слэши. Помимо их очевидного преимущества в подобных случаях, они позволяют иметь кроссплатформенные документы. Сейчас имею дело с $\LaTeX$-документом со сложной структурой (используется разветвленная иерархия каталогов), который использует относительные пути с прямыми слэшами и прекрасно компилируется одновременно под Windows, Mac OS и Linux (везде в качестве дистрибутива используется TeX Live [на Mac OS — MacTeX]).

Кстати, от import пришлось отказаться в пользу банальных input/include.

P.S. Собственно, если Вам не приходится пользоваться UNC-путями, про обратные слэши под Windows можно вообще забыть как про страшный и нелепый сон. Кажется, во всех остальных сферах применения прямые слэши можно использовать наравне с обратными в путях к файлам и каталогам.

[Lenchik]

нормально работает

Используется синтаксис LaTeX

\subinputfrom{images_tikz/}{article_graph.tikz}

Используется синтаксис LaTeX

\subinputfrom{./}{common.tex}

Себе сделал заметку

Цитата:

Внимательно читать документацию пакета про последовательность перебора путей при возникновении проблем. Особенно если есть файлы с одинаковыми именами в директориях разной вложенности.

[venco]

EtCetera в сообщении #1187637 писал(а):

Собственно, если Вам не приходится пользоваться UNC-путями, про обратные слэши под Windows можно вообще забыть как про страшный и нелепый сон.

В UNC прямые слеши тоже работают. Проблема только в аргументах некоторых программ, в том числе системных - они тупо воспринимают прямой слеш как ключи:

C:\Temp>dir C:\Temp
 Volume in drive C is Local Disk
 Volume Serial Number is ****-****

 Directory of C:\Temp

01/26/2017  03:56 PM    <DIR>          .
01/26/2017  03:56 PM    <DIR>          ..
07/11/2013  10:42 AM             1,188 c_studio_2013_inst-log.txt
07/11/2013  10:44 AM             1,724 vtune_2013_inst-log.txt
               2 File(s)          2,912 bytes
               2 Dir(s)  370,308,435,968 bytes free

C:\Temp>dir C:/Temp
Parameter format not correct - "emp".

[Lenchik]

А заключите в кавычки и будет нормалёк.

[EtCetera]

venco в сообщении #1187649 писал(а):

В UNC прямые слеши тоже работают.

Почему-то у меня было застарелое ощущение, что cmd (а, возможно, и кто-то еще) не переваривает прямые слэши в UNC-путях (в отличие от PowerShell). Но сейчас попробовал, и вроде бы все нормально (если обрамлять путь кавычками, конечно).

-- Пт янв 27, 2017 01:11:02 --

venco
Все-таки мои ощущения имеют под собой основания. Прямые слэши нельзя использовать в UNC-путях к файлам с префиксом \\?\ (с помощью которого задаются пути с расширенной длиной):

Документация MSDN по Windows Desktop App Development в статье Naming Files, Paths, and Namespaces писал(а):

The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

Выделение курсивом мое.

Странным образом, хотя в этом отрывке вроде бы говорится только о UNC-путях (с префиксом \\?\UNC\), но в cmd не работают и обычные пути с префиксом \\?\, содержащие прямые слэши. Попробуйте сравнить результат выполнения таких команд в cmd:

• dir \\?\C:\
• dir "\\?\C:/"

А вот PowerShell категорически отказывается переваривать пути с префиксом \\?\.
И cmd почему-то не хочет работать с файлами и каталогами с префиксом \\?\UNC\ (вроде \\?\UNC\ServerName\SharedFolder\).

[arctium]

Да, действительно, прямые слэши работают, скобка закрывается как надо.
Теперь TeX просто выдает сообщение File not found.

[Walker_XXI]

arctium в сообщении #1187797 писал(а):

Теперь TeX просто выдает сообщение File not found.

Пробелов в имени нет? Может помогут кавычки?

[arctium]

Кавычки не помогают. Ничего не помогает. Печаль.

[Lenchik]

ну так последовательно ищите проблему
файл назовите a.pdf, он должен реально существовать.
помещаете в путь c:/, работает?
Если да, идёте дальше по пути и тестите в каждой точке.
А то может путь у вас
c:/MyDocuments/Великий Властелин Василий/доку$мен!тики/.../MyBook/Chapter1/
и файл зовется
невообразимый кошмар от современного пользователя.pdf