Какое наиболее правильное регулярное выражение для пути к файлу UNIX?

Question

Какое наиболее правильное регулярное выражение (регулярное выражение) для пути к файлу UNIX?

Например, чтобы обнаружить что-то вроде этого:

/usr/lib/libgccpp.so.1.0.2

Довольно просто создать регулярное выражение, которое будет соответствовать большинству файлов, но самое лучшее, в том числе такое, которое может обнаруживать экранированные последовательности пробелов и необычные символы, которые вы обычно не найдете в путях к файлам в UNIX.

Кроме того, существуют ли функции библиотеки на нескольких различных языках программирования, обеспечивающие регулярное выражение для пути к файлу?

Answer 1

Если вы не возражаете против ложных срабатываний для определения путей, то вам просто нужно убедиться, что путь не содержит символа NUL; все остальное разрешено (в частности, / является символом разделителя имен). Лучшим подходом было бы разрешить заданный путь, используя соответствующую функцию ввода-вывода файла (например, File.exists(), File.getCanonicalFile() в Java).

Длинный ответ:

Это и операционная система и файловая система зависимая. Например, сравнение файловых систем Wikipedia отмечает, что помимо ограничений, налагаемых файловой системой,

MS-DOS, Microsoft Windows и OS / 2 запретить символы \ / : ? * " > < | и NUL в файле и каталоге имена во всех файловых системах . юниксов и Linux запрещают символы / и NUL в именах файлов и каталогов во всех файловых системах .

В Windows следующие зарезервированные имена устройств также не допускаются в качестве имен файлов:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5,
COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, 
LPT5, LPT6, LPT7, LPT8, LPT9

Answer 2

Правильное регулярное выражение для соответствия всем путям UNIX: [^ \ 0] +

То есть один или несколько символов, которые не равны NUL.

Answer 3

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

Так, например, допустимый путь будет

  /usr/bin/program\ with\ space 

в отличие от

  /usr/bin/program with space 

который будет ссылаться на "/ usr / bin / program" с аргументами "with" и "space"

Регулярное выражение для приведенного выше примера может быть "([^ \ 0] \ | \\) *"

Регулярное выражение, над которым я работал, (новая строка отделена для «читабельности»):

  "\(                    # Either
       [^\0 !$`&*()+]    # A normal (non-special) character
     \|                  # Or
       \\\(\ |\!|\$|\`|\&|\*|\(|\)|\+\)   # An escaped special character
   \)\+"                   # Repeated >= 1 times

Что переводится как

  "\([^\0 !$`&*()+]\|\\\(\ |\!|\$|\`|\&|\*|\(|\)|\+\)\)\+"

Создание собственного конкретного регулярного выражения также должно быть относительно простым.

Answer 4

^(/)?([^/\0]+(/)?)+$

Принимает все допустимые пути в файловых системах, такие как extX , reiserfs .

Он отбрасывает только имена путей, содержащие NUL или двойные (или более) косые черты. Все остальное в соответствии со спецификацией Unix должно быть законным (я тоже удивлен этим результатом).

Answer 5

Я не уверен, насколько распространена проверка регулярных выражений для всех систем, но большинство языков программирования (особенно кроссплатформенных) предоставляют проверку "файл существует", которая будет учитывать такие вещи

Из любопытства, где эти пути вводятся? Не могли бы вы контролировать это до такой степени, что вам не придется проверять отдельные части пути? Например, используя диалог выбора файлов?

Answer 6

На вопрос уже дан ответ: https://stackoverflow.com/a/42036026/1951947