Как стать автором
Обновить

Комментарии 22

Одинарные кавычки в Перле — это не полное отключение эскейпинга.
print 'c:\\x.txt';
напечатает c:\x.txt

Ну, это как раз, выходит, очень продуманная особенность. С нею можно написать


print 'c:\\';

и получить


c:\
Разумеется, просто я имел в виду, что одинарные кавычки не означают стопроцентно литеральный текст.
` встречается в MySQL для экранирования имен. Это печально.
Во всех, или почти во всех, примерах проблемы из-за неудачно выбранного в окнах разделителе файловых путей или ключей реестра. Может попробуете использовать более родной разделитель — '/'?
Это вы мне так вежливо предлагаете ОС сменить?) На самом деле, некоторые библиотеки мирятся с использованием простой косой черты вместо обратной для определения путей в Windows, но ведь не все, не совсем универсально выходит. Но повод вспомнить о пресловутом неудачном выборе разделителя создателями Windows опять всплывает, это правда.

По секрету скажу, что windows понимает оба варианта. А если какая-либо библиотека велосипедит свою валидацию — пишите багрепорты.

По ещё большему секрету скажу, что Windows перестаёт понимать прямой слэш, если используется префикс \\?\, необходимый для работы с длинными путями и «запрещёнными» именами.

Обратный слеш нужен только в префиксе. Дальше все нормально воспринимается как минимум со времен XP. Оба варианта ниже работоспособны:


\\./C:/boot.ini
\\?/C:/boot.ini

Единственная причина использовать обратные слеши в Windows — это то, что всякие встроенные команды типа dir воспринимают прямой слеш, как начало параметра.

Эти варианты работоспособны ровно в той степени, в какой работоспособны обычные пути без префиксов. Длинный путь, превышающий MAX_PATH, с любым из этих двух префиксов выдаст ошибку. Чтобы обработать длинный путь, необходимо задавать именно \\?\ (с обратными слэшами) и обратные слэши в пути.

Вот объяснение (немного про другие префиксы, но схема должна быть та же):
http://stackoverflow.com/a/25099634/2182162

Почему же тогда в руководствах советуют воздерживаться от использования конкретных разделителей для кросс-платформенности? Можно было бы во всех случаях использовать простую косую черту.

Да, можно и нужно использовать слеш. А если в руководстве даются рекомендации без пояснений, значит автор и сам не в курсе что и зачем.


@CaptainFlint а если в редких кейсах и требуется обратный слеш, то именно в этих местах делать .replace( /\//g , '\\' ), а не рассовывать по всем библиотекам костыли вида "Hello" + require('os').EOL + "World".

Не уверен, что это удобно. В большом проекте замучаешься отслеживать все такие места. Одно пропустишь — потом фиг отловишь. Уж проще обёртки использовать, которые всё приводят к единому системному виду.

Кроме того, в проекте может использоваться сторонняя библиотека, которая все пути автоматом приводит к префиксному виду (скажем, автор решил, что надо поддерживать длинные пути). И в эту библиотеку надо передавать обратный слэш, а во всех остальных местах программы использовать прямой? Такой подход только усугубит путаницу. В общем, всё зависит от конкретной ситуации. Просто надо иметь в виду эту особенность работы в Windows.

Именно в обёртках и надо писать все эти OS-специфичные штуки типа .replace( /\//g , '\\' ), чтобы абстрагировать пользовательский код от конкретной OS.

Недавно наткнулся на такую библиотеку: https://github.com/declandewet/common-tags. Может, что-нибудь в этом роде позволит отказаться от вещей типа ${'\\'}.

Возможно, хотя именно эта библиотека имеет несколько более крупную цель (на днях о ней вышла статья на авторитетном ресурсе, а не так давно я тоже пробовал соорудить что-то совсем простое в этом направлении). Но описанная проблема слишком низкоуровневая. Единственное, что мне приходит в голову, это сделать вариант String.raw с добавлением trim(), чтобы можно было использовать конечную косую черту с пробелом.

Да, именно там я ее и увидел.
Я к тому, что у таких трюков большой потенциал. Я-то вряд ли порох изобрету, а вас или автора библиотеки, может, вдохновит на что-то интересное.

Ну, у меня, честно говорят, нет ни опыта, ни знаний писать универсальные библиотеки, я просто программист-любитель. Но будем надеяться, что и правда кто-то всё упростит)

Глядя с точки зрения человека, потенциально поддерживающего данный код, лучше не используйте это вообще. Так и представляю, меняется путь до файла, код перестаёт парситься посреди строки и счастливой отладки. Лучше бы он был со всем экранированием: некрасиво, но предсказуемо.

Ну и ограничения, очевидно, не обойти, раз они на уровне парсера. Можно перейти на что-то транслируемое в JS, где есть нужная функциональность, но это, опять же, дикий оверкилл. Зато не хак.

Ну, я бы вообще не рисковал зашивать пути во что-то, отдаваемое в общее пользование. Я это скорее для личных локальных утилит применяю. Но вот с регулярками вроде бы безопасно использовать и в общих проектах.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории