Подтвердить что ты не робот

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

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

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

/usr/lib/libgccpp.so.1.0.2

Очень легко сделать регулярное выражение, которое будет соответствовать большинству файлов, но самое лучшее, в том числе одно, которое может обнаружить escape-последовательности в виде пробелов, и необычные символы, которые обычно не встречаются в пути к файлам в UNIX.

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

  /usr/bin/program\ with\ space

в отличие от

  /usr/bin/program with space

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

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

Я работаю над регулярным выражением (новая строка разделена на "читаемость" ):

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

Что означает

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

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

Ответ 4

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

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

Ответ 5

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

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

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