Каковы недокументированные функции и ограничения команды Windows FINDSTR?

Команда Windows FINDSTR ужасно задокументирована. Существует очень простая справка по командной строке, доступная через FINDSTR /?или HELP FINDSTR, но она крайне неадекватна. На сайте https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr можно найти немного больше документации .

Существует множество функций и ограничений FINDSTR, которые даже не упоминаются в документации. Также их нельзя было ожидать без предварительного знания и / или тщательного экспериментирования.

Итак, вопрос в том, каковы недокументированные особенности и ограничения FINDSTR?

Цель этого вопроса - предоставить единый репозиторий многих недокументированных функций, чтобы:

А) Разработчики могут в полной мере воспользоваться функциями, которые там есть.

Б) Разработчики не тратят свое время на размышления о том, почему что-то не работает, когда кажется, что должно.

Пожалуйста, убедитесь, что вы знаете существующую документацию, прежде чем ответить. Если информация покрыта ПОМОЩЬЮ, то она здесь не принадлежит.

Также это не место, чтобы показать интересные применения FINDSTR. Если логический человек может предвидеть поведение конкретного использования FINDSTR на основе документации, то он не относится к этому.

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

Предисловие
Большая часть информации в этом ответе была собрана на основе экспериментов, проведенных на компьютере с Vista. Если прямо не указано иное, я не подтвердил, применима ли информация к другим версиям Windows.

Вывод FINDSTR
Документация никогда не объясняет вывод FINDSTR. Это намекает на то, что печатаются совпадающие строки, но не более того.

Формат соответствия строки выводится следующим образом:

Имя файла: LINENUMBER: lineOffset: текст

где

fileName: = Имя файла, содержащего совпадающую строку. Имя файла не печатается, если запрос был явно для одного файла, или при поиске вводимых по трубопроводу входов или перенаправленных входных данных. При печати fileName всегда будет содержать любую предоставленную информацию о пути. Дополнительная информация о пути будет добавлена, если используется эта/Sопция. Печатный путь всегда указывается относительно предоставленного пути или относительно текущего каталога, если он не указан.

Примечание. Префикса имени файла можно избежать при поиске в нескольких файлах с использованием нестандартных (и плохо документированных) подстановочных знаков < и >. Точные правила работы этих подстановочных знаков можно найти здесь . Наконец, вы можете посмотреть на этот пример того, как нестандартные символы подстановки работают с FINDSTR .

lineNumber: = Номер строки совпадающей строки, представленной в виде десятичного значения, где 1 представляет 1-ю строку ввода. Распечатывается, только если/Nуказана опция.

lineOffset: = десятичное смещение байта начала совпадающей строки, где 0 представляет 1-й символ 1-й строки. Распечатывается, только если/Oуказана опция. Это не смещение совпадения в строке. Это число байтов от начала файла до начала строки.

text = двоичное представление совпадающей строки, включая любые <CR> и / или <LF>. Ничего не осталось из двоичного вывода, так что этот пример, который соответствует всем строкам, даст точную двоичную копию исходного файла.

FINDSTR "^" FILE >FILE_COPY

Параметр / A задает цвет только для fileName :, lineNumber: и lineOffset: output. Текст соответствующей строки всегда выводится с текущим цветом консоли. Параметр / A действует только тогда, когда вывод отображается непосредственно на консоли. Параметр / A не действует, если выходные данные перенаправляются в файл или передаются по конвейеру. Смотрите описание 2018-08-18 в ответе Aacini для описания ошибочного поведения при перенаправлении вывода в CON.

Большинство контрольных символов и многие расширенные символы ASCII отображаются в виде точек в XP.
FINDSTR в XP отображает большинство непечатаемых контрольных символов из соответствующих строк в виде точек (точек) на экране. Следующие управляющие символы являются исключениями; они отображаются как сами: вкладка 0x09, перевод строки 0x0A, вертикальная вкладка 0x0B, подача формы 0x0C, возврат каретки 0x0D.

XP FINDSTR также преобразует ряд расширенных символов ASCII в точки. Расширенные символы ASCII, которые отображаются как точки в XP, такие же, как те, которые преобразуются при вводе в командной строке. См. Раздел «Ограничения символов для параметров командной строки - Расширенное преобразование ASCII» , далее в этом посте.

Управляющие символы и расширенный ASCII не преобразуются в точки в XP, если выходные данные передаются по конвейеру, перенаправляются в файл или в предложении FOR IN ().

Vista и Windows 7 всегда отображают все символы как сами по себе, а не как точки.

Коды возврата (ОШИБКА)

• 0 (успех)
  • Найдено совпадение хотя бы в одной строке хотя бы одного файла.
• 1 (сбой)
  • Не найдено совпадений ни в одной строке файла.
  • Неверный цвет, указанный в /A:xxопции
• 2 (ошибка)
  • Несовместимые параметры /Lи /Rоба указанных
  • Отсутствует аргумент после /A:, /F:, /C:, /D:, или/G:
  • Файл указан /F:fileили /G:fileне найден
• 255 (ошибка)
  • Слишком много терминов класса символов в регулярном выражении,
    см. Предел термина класса символов Regex и сообщение об ошибке во второй части ответа.

Источник данных для поиска (Обновлено на основе тестов с Windows 7)
Findstr может искать данные только из одного из следующих источников:

• имена файлов, указанные в качестве аргументов и / или с помощью /F:fileопции.

• стандартный ввод через перенаправление findstr "searchString" <file

• поток данных из трубы type file | findstr "searchString"

Аргументы / опции имеют приоритет над перенаправлением, которое имеет приоритет над переданными данными.

Аргументы имени файла и /F:fileмогут быть объединены. Можно использовать несколько аргументов имени файла. Если /F:fileуказано несколько параметров, используется только последний. Подстановочные знаки допускаются в аргументах имени файла, но не в пределах файла, на который указывает /F:file.

Источник строк поиска (обновляется на основе тестов с Windows 7) и опции могут быть объединены. Можно указать несколько параметров. Если указано несколько параметров, используется только последний. Если какая- либо или используется, то все аргументы , не вариант предполагаются файлы для поиска. Если ни то, ни другое не используется, то первый неопциональный аргумент обрабатывается как список поисковых терминов, разделенных пробелом.
/G:file/C:string/C:string/G:file/G:file/C:string/G:file/C:string

Имена файлов не должны заключаться в кавычки внутри файла при использовании /F:FILEопции.
Имена файлов могут содержать пробелы и другие специальные символы. Большинство команд требуют, чтобы такие имена файлов были заключены в кавычки. Но /F:files.txtопция FINDSTR требует, чтобы имена файлов в файле files.txt НЕ цитировались. Файл не будет найден, если имя указано в кавычках.

BUG - Short 8.3 имена файлов могут сломать /Dи /Sпараметры
Как и со всеми командами Windows, FINDSTR будет пытаться соответствовать как длинное имя и краткое 8.3 имя при поиске файлов для поиска. Предположим, что текущая папка содержит следующие непустые файлы:

b1.txt
b.txt2
c.txt

Следующая команда успешно найдет все 3 файла:

findstr /m "^" *.txt

b.txt2совпадает, потому что соответствующее короткое имя B9F64~1.TXTсовпадает. Это согласуется с поведением всех других команд Windows.

Но ошибка с /Dи /Sопциями вызывает следующие команды лишь найтиb1.txt

findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt

Ошибка не может b.txt2быть найдена, как и все имена файлов, которые сортируются b.txt2в одном и том же каталоге. Дополнительные файлы, которые сортируют, как a.txt, например , найдены. Дополнительные файлы, которые сортируются позже, например d.txt, пропускаются после того, как ошибка была вызвана.

Каждый найденный каталог обрабатывается независимо. Например, эта /Sопция будет успешно начинать поиск в дочерней папке после невозможности найти файлы в родительской папке, но как только ошибка приведет к тому, что короткое имя файла будет пропущено в дочерней папке, тогда все последующие файлы в этой дочерней папке также будут пропущены. ,

Команды работают без ошибок, если на компьютере с отключенной генерацией имен NTFS 8.3 созданы одинаковые имена файлов. Конечно b.txt2, не будет найден, но c.txtбудет найден правильно.

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

Ошибка была подтверждена на XP, Vista и Windows 7.

Непечатаемые символы и /Pвариант опция заставляет FINDSTR пропустить какой - либо файл , который содержит любой из следующих кодов байт десятичных: 0-7, 14-25, 27-31.
/P

Другими словами, /Pопция будет пропускать только те файлы, которые содержат непечатные управляющие символы. Управляющие символы - это коды, которые меньше или равны 31 (0x1F). FINDSTR рассматривает следующие управляющие символы как печатные:

 8  0x08  backspace
 9  0x09  horizontal tab
10  0x0A  line feed
11  0x0B  vertical tab
12  0x0C  form feed
13  0x0D  carriage return
26  0x1A  substitute (end of text)

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

Вводные данные с перенаправленным вводом могут быть <CR><LF>добавлены.
Если входные данные переданы по конвейеру, а последний символ потока отсутствует <LF>, FINDSTR автоматически добавится <CR><LF>к входным данным. Это было подтверждено в XP, Vista и Windows 7. (Раньше я думал, что канал Windows был ответственен за изменение ввода, но с тех пор я обнаружил, что FINDSTR фактически делает изменение.)

То же самое верно для перенаправленного ввода в Vista. Если последний символ файла, используемого в качестве перенаправленного ввода, не является <LF>, FINDSTR автоматически добавится <CR><LF>к вводу. Однако XP и Windows 7 не изменяют перенаправленный ввод.

FINDSTR зависает в XP и Windows 7, если перенаправленный ввод не заканчивается.<LF>
Это неприятная «особенность» в XP и Windows 7. Если последний символ файла, используемого в качестве перенаправленного ввода, не заканчивается <LF>, FINDSTR будет зависать бесконечно, как только он достигает конца перенаправленного файла.

Последняя строка данных Piped может игнорироваться, если она состоит из одного символа.
Если ввод передается по конвейеру, а последняя строка состоит из одного символа, за которым не следует <LF>, то FINDSTR полностью игнорирует последнюю строку.

Пример - первая команда с одним символом и без <LF>совпадения, но вторая команда с 2 символами работает нормально, как и третья команда с одним символом с завершающим символом новой строки.

> set /p "=x" <nul | findstr "^"

> set /p "=xx" <nul | findstr "^"
xx

> echo x| findstr "^"
x

Об этом сообщает пользователь DosTips Sponge Belly на новой ошибке findstr . Подтверждено на XP, Windows 7 и Windows 8. Еще не слышал о Vista. (У меня больше нет Vista для тестирования).

Синтаксис
опций Опция может иметь префикс либо либо, /либо - опции могут объединяться после одного /или -. Однако объединенный список параметров может содержать не более одного параметра с несколькими символами, например OFF или F:, и параметр из нескольких символов должен быть последним параметром в списке.

Ниже приведены все эквивалентные способы выражения регистрозависимого поиска без учета регистра для любой строки, которая содержит слова «привет» и «до свидания» в любом порядке.

• /i /r /c:"hello.*goodbye" /c:"goodbye.*hello"

• -i -r -c:"hello.*goodbye" /c:"goodbye.*hello"

• /irc:"hello.*goodbye" /c:"goodbye.*hello"

Ограничения длины строки поиска
В Vista максимально допустимая длина одной строки поиска составляет 511 байт. Если какая-либо строка поиска превышает 511, то результатом будет FINDSTR: Search string too long.ошибка ERRORLEVEL 2.

При выполнении поиска по регулярному выражению максимальная длина строки поиска равна 254. Регулярное выражение с длиной от 255 до 511 приведет к FINDSTR: Out of memoryошибке с ошибкой 2. Длина регулярного выражения> 511 приведет к FINDSTR: Search string too long.ошибке.

В Windows XP длина строки поиска явно меньше. Ошибка Findstr: «Слишком длинная строка поиска»: как извлечь и сопоставить подстроку в цикле «for»? Ограничение XP составляет 127 байтов для литерального и регулярного поиска.

Ограничения длины строки
Файлы, указанные в качестве аргумента командной строки или с помощью параметра / F: FILE, не имеют известного ограничения длины строки. Поиск был успешно выполнен для файла размером 128 МБ, который не содержал ни одного <LF>.

Данные по конвейеру и перенаправленный ввод ограничены 8191 байтами на строку. Этот лимит является «особенностью» FINDSTR. Это не присуще трубам или перенаправлению. FINDSTR, использующий перенаправленный ввод stdin или piped, никогда не будет соответствовать ни одной строке размером> = 8 Кбайт. Строки> = 8k генерируют сообщение об ошибке для stderr, но значение ERRORLEVEL равно 0, если строка поиска найдена хотя бы в одной строке хотя бы одного файла.

Тип поиска по умолчанию: Литерал против Регулярного выражения
/C:"string" - по умолчанию это / L литерал. Явное объединение параметра / L с / C: «строка», безусловно, работает, но является избыточным.

"string argument"- Значение по умолчанию зависит от содержимого самой первой строки поиска. (Помните, что <пробел> используется для разделения строк поиска.) Если первая строка поиска является допустимым регулярным выражением, которое содержит хотя бы один неэкранированный метасимвол, то все строки поиска обрабатываются как регулярные выражения. В противном случае все строки поиска рассматриваются как литералы. Например, "51.4 200"будет обрабатываться как два регулярных выражения, поскольку первая строка содержит неэкранированную точку, тогда как "200 51.4"будет рассматриваться как два литерала, поскольку первая строка не содержит метасимволов.

/G:file- Значение по умолчанию зависит от содержимого первой непустой строки в файле. Если первая строка поиска является допустимым регулярным выражением, которое содержит хотя бы один неэкранированный метасимвол, то все строки поиска обрабатываются как регулярные выражения. В противном случае все строки поиска рассматриваются как литералы.

Рекомендация - всегда явно указывайте /Lопцию литерала или опцию /Rрегулярного выражения при использовании "string argument"или /G:file.

ОШИБКА - Задание нескольких литеральных строк поиска может дать ненадежные результаты

В следующем простом примере FINDSTR не удается найти совпадение, даже если оно должно.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

Эта ошибка была подтверждена в Windows Server 2003, Windows XP, Vista и Windows 7.

Основываясь на экспериментах, FINDSTR может потерпеть неудачу, если выполнены все следующие условия:

• В поиске используются несколько литеральных строк поиска.
• Строки поиска имеют разную длину
• Короткая строка поиска имеет некоторое перекрытие с более длинной строкой поиска
• Поиск чувствителен к регистру (без /Iопции)

При каждом сбое, которое я видел, всегда происходит сбой одной из коротких строк поиска.

Для получения дополнительной информации см. Почему этот пример FINDSTR с несколькими литеральными строками поиска не находит соответствия?

Кавычки и обратные слэши в аргументах командной строки
Примечание. Комментарии пользователя MC ND отражают действительно ужасно сложные правила для этого раздела. Есть 3 различных этапа анализа:

• Первый cmd.exe может потребовать экранировать некоторые кавычки как ^ "(на самом деле ничего общего с FINDSTR)
• Далее FINDSTR использует синтаксический анализатор аргументов C / C ++ до 2008 года , который имеет специальные правила для "и \".
• После завершения синтаксического анализа аргумента FINDSTR дополнительно обрабатывает \, сопровождаемый буквенно-цифровым символом, как литерал, но \ сопровождаемый не буквенно-цифровым символом, как escape-символ

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

Экранирование
кавычек в строках поиска командной строки Кавычки в строках поиска командной строки должны быть экранированы с помощью обратной косой черты \". Это верно как для литеральных, так и для регулярных выражений поисковых строк. Эта информация была подтверждена на XP, Vista и Windows 7.

Примечание. Может также потребоваться экранирование кавычки для синтаксического анализатора CMD.EXE, но это не имеет ничего общего с FINDSTR. Например, для поиска одной цитаты вы можете использовать:

FINDSTR \^" file && echo found || echo not found

Экранирование обратной косой черты в строке поиска литералов командной строки Обратная косая черта в строке поиска
литералов обычно может быть представлена ​​как \или как \\. Они, как правило, эквивалентны. (В Vista могут быть необычные случаи, когда обратная косая черта всегда должна быть экранирована, но у меня больше нет машины Vista для тестирования) .

Но есть несколько особых случаев:

При поиске последовательных обратных слэшей все, кроме последнего, должны быть экранированы. Последний обратный слеш может быть при желании экранирован.

• \\может быть закодировано как \\\или\\\\
• \\\может быть закодировано как \\\\\или\\\\\\

Поиск одной или нескольких обратных косых черт перед тем, как цитата будет странной. Логика подсказывает, что нужно избегать кавычек, а каждую из ведущих обратных косых черт нужно избегать, но это не работает! Вместо этого каждый из ведущих обратных слэшей должен быть дважды экранирован, а кавычка экранирована как обычно:

• \" должен быть закодирован как \\\\\"
• \\" должен быть закодирован как \\\\\\\\\"

Как отмечалось ранее, для одной или нескольких экранированных кавычек может также потребоваться экранирование ^для синтаксического анализатора CMD

Информация в этом разделе была подтверждена на XP и Windows 7.

Экранирование обратной косой черты в строке поиска регулярных выражений в командной строке

• Только для Vista: обратная косая черта в регулярном выражении должна быть либо с двойным экранированием \\\\, либо с одиночным экранированием в наборе классов символов, например [\\]

• XP и Windows 7: обратную косую черту в регулярном выражении всегда можно представить как [\\]. Обычно это можно представить как \\. Но это никогда не работает, если обратный слеш предшествует экранированной кавычке.

  Одна или несколько обратных косых черт перед экранированной кавычкой должны быть либо экранированы дважды, либо кодированы как [\\]

  • \"может быть закодировано как \\\\\"или[\\]\"
  • \\"может быть закодировано как \\\\\\\\\"или [\\][\\]\"или\\[\\]\"

Экранирование
кавычек и обратной косой черты в литеральных строках поиска / G: FILE Автономные кавычки и обратные косые черты в файле литеральных строк поиска, указанных в / G: file, не нужно экранировать, но они могут быть.

"и \"эквивалентны.

\и \\эквивалентны.

Если цель состоит в том, чтобы найти \\, то, по крайней мере, должен быть экранирован ведущий обратный слеш. Оба \\\и \\\\работают.

Если цель состоит в том, чтобы найти \ ", то, по крайней мере, должен быть экранирован ведущий обратный слеш. И то \\"и другое \\\"работает.

Экранирование кавычек и обратной косой черты в / G: строки поиска по регулярному выражению FILE
Это единственный случай, когда escape-последовательности работают, как и ожидалось, основываясь на документации. Цитата не является метасимволом регулярных выражений, поэтому ее не нужно экранировать (но можно). Обратная косая черта является метасимволом регулярных выражений, поэтому ее необходимо экранировать.

Пределы символов для параметров командной строки - Расширенное преобразование ASCII
Нулевой символ (0x00) не может появляться ни в одной строке командной строки. Любой другой однобайтовый символ может появиться в строке (0x01 - 0xFF). Однако FINDSTR преобразует многие расширенные символы ASCII, которые он находит в параметрах командной строки, в другие символы. Это оказывает серьезное влияние двумя способами:

1) Многие расширенные символы ASCII не будут совпадать, если они используются в качестве строки поиска в командной строке. Это ограничение одинаково для литеральных и регулярных поисков. Если строка поиска должна содержать расширенный ASCII, тогда /G:FILEследует использовать эту опцию.

2) FINDSTR может не найти файл, если имя содержит расширенные символы ASCII и имя файла указано в командной строке. Если файл для поиска содержит расширенный ASCII в имени, тогда /F:FILEвместо этого следует использовать эту опцию.

Вот полный список расширенных преобразований символов ASCII, которые FINDSTR выполняет в строках командной строки. Каждый символ представлен в виде десятичного значения байтового кода. Первый код представляет символ, указанный в командной строке, а второй код представляет символ, в который он преобразован. Обратите внимание - этот список был составлен на американском компьютере. Я не знаю, какое влияние на этот список могут оказать другие языки.

158 treated as 080     199 treated as 221     226 treated as 071
169 treated as 170     200 treated as 043     227 treated as 112
176 treated as 221     201 treated as 043     228 treated as 083
177 treated as 221     202 treated as 045     229 treated as 115
178 treated as 221     203 treated as 045     231 treated as 116
179 treated as 221     204 treated as 221     232 treated as 070
180 treated as 221     205 treated as 045     233 treated as 084
181 treated as 221     206 treated as 043     234 treated as 079
182 treated as 221     207 treated as 045     235 treated as 100
183 treated as 043     208 treated as 045     236 treated as 056
184 treated as 043     209 treated as 045     237 treated as 102
185 treated as 221     210 treated as 045     238 treated as 101
186 treated as 221     211 treated as 043     239 treated as 110
187 treated as 043     212 treated as 043     240 treated as 061
188 treated as 043     213 treated as 043     242 treated as 061
189 treated as 043     214 treated as 043     243 treated as 061
190 treated as 043     215 treated as 043     244 treated as 040
191 treated as 043     216 treated as 043     245 treated as 041
192 treated as 043     217 treated as 043     247 treated as 126
193 treated as 045     218 treated as 043     249 treated as 250
194 treated as 045     219 treated as 221     251 treated as 118
195 treated as 043     220 treated as 095     252 treated as 110
196 treated as 045     222 treated as 221     254 treated as 221
197 treated as 043     223 treated as 095
198 treated as 221     224 treated as 097

Любой символ> 0, отсутствующий в приведенном выше списке, рассматривается как сам по себе, включая <CR>и < LF>. Самый простой способ включить нечетные символы, такие как <CR>и, <LF>- это поместить их в переменную окружения и использовать отложенное расширение в аргументе командной строки.

Пределы символов для строк, найденных в файлах, указанных в параметрах / G: FILE и / F: FILE
Символ nul (0x00) может появляться в файле, но он действует как терминатор строки C. Любые символы после нулевого символа обрабатываются как другая строка, как если бы они были в другой строке.

<CR>И <LF>символы рассматриваются как линейные терминаторы , которые завершаются строки, и не включаются в строку.

Все остальные однобайтовые символы полностью включены в строку.

Поиск файлов Unicode
FINDSTR не может правильно искать большинство Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), потому что он не может искать нулевые байты, а Unicode обычно содержит много нулевых байтов.

Однако команда TYPE преобразует UTF-16LE с BOM в однобайтовый набор символов, поэтому такая команда будет работать с UTF-16LE с BOM.

type unicode.txt|findstr "search"

Обратите внимание, что кодовые точки Unicode, которые не поддерживаются вашей активной кодовой страницей, будут преобразованы в ?символы.

Поиск в UTF-8 возможен, если строка поиска содержит только ASCII. Однако вывод на консоль любых многобайтовых символов UTF-8 будет неправильным. Но если вы перенаправите вывод в файл, то результат будет правильно закодирован UTF-8. Обратите внимание, что если файл UTF-8 содержит спецификацию, то эта спецификация будет рассматриваться как часть первой строки, что может привести к сбою в поиске, который соответствует началу строки.

Можно искать многобайтовые символы UTF-8, если поместить строку поиска в файл поиска в кодировке UTF-8 (без спецификации) и использовать параметр / G.

Конец строки
FINDSTR разрывает строки сразу после каждого <LF>. Наличие или отсутствие <CR> не влияет на разрывы строк.

Поиск через разрывы строк
Как и ожидалось, .метасимвол регулярного выражения не будет совпадать с <CR> или <LF>. Но можно искать через разрыв строки, используя строку поиска командной строки. Символы <CR> и <LF> должны совпадать явно. Если найдено многострочное совпадение, печатается только 1-я строка совпадения. Затем FINDSTR удваивается до 2-ой строки в источнике и снова начинает поиск - что-то вроде функции «смотреть вперед».

Предположим, что TEXT.TXT содержит это содержимое (может быть в стиле Unix или Windows)

A
A
A
B
A
A

Тогда этот скрипт

@echo off
setlocal
::Define LF variable containing a linefeed (0x0A)
set LF=^


::Above 2 blank lines are critical - do not remove

::Define CR variable containing a carriage return (0x0D)
for /f %%a in ('copy /Z "%~dpf0" nul') do set "CR=%%a"

setlocal enableDelayedExpansion
::regex "!CR!*!LF!" will match both Unix and Windows style End-Of-Line
findstr /n /r /c:"A!CR!*!LF!A" TEST.TXT

дает эти результаты

1:A
2:A
5:A

Поиск по разрывам строк с использованием параметра / G: FILE является неточным, поскольку единственный способ сопоставить <CR> или <LF> - это выражение диапазона классов символов регулярного выражения, которое помещает символы EOL в сэндвич.

• [<TAB>-<0x0B>] соответствует <LF>, но также соответствует <TAB> и <0x0B>

• [<0x0C>-!] соответствует <CR>, но также соответствует <0x0C> и!

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

Ответ продолжен в части 2 ниже ...

Продолжение ответа с части 1 выше - я столкнулся с лимитом 30 000 символов :-(

Ограниченные регулярные выражения (регулярное выражение) Поддержка
FINDSTR для регулярных выражений крайне ограничена. Если его нет в документации HELP, он не поддерживается.

Кроме того, поддерживаемые выражения регулярных выражений реализованы совершенно нестандартным образом, так что результаты могут отличаться от ожидаемых от чего-то вроде grep или perl.

Regex Line Position anchors ^ и $
^ соответствует началу входного потока, а также любой позиции, следующей сразу за <LF>. Поскольку FINDSTR также разбивает строки после <LF>, простое регулярное выражение «^» всегда будет соответствовать всем строкам в файле, даже двоичному файлу.

$соответствует любой позиции, непосредственно предшествующей <CR>. Это означает, что строка поиска регулярного выражения $никогда не будет совпадать ни с одной строкой в ​​текстовом файле стиля Unix, а также с последней строкой текстового файла Windows, если в ней отсутствует маркер EOL для <CR> <LF>.

Примечание. Как уже говорилось ранее, возможно, <CR><LF>что к FINDSTR добавлен канал и перенаправленный ввод , которого нет в источнике. Очевидно, что это может повлиять на поиск регулярных выражений, который использует $.

Любая строка поиска с символами до ^или после $всегда не сможет найти совпадение.

Позиционные опции / B / E / X
Позиционные опции работают так же, как ^и $, за исключением того, что они также работают для буквенных строк поиска.

/ B работает так же, как ^в начале строки поиска регулярных выражений.

/ E работает так же, как $в конце строки поиска регулярного выражения.

/ X работает так же, как и ^в начале, и $в конце строки поиска регулярного выражения.

Граница слова
\< регулярного выражения должна быть самым первым термином в регулярном выражении. Регулярное выражение не будет соответствовать чему-либо, если ему предшествуют другие символы. \<соответствует либо самому началу ввода, началу строки (позиции, следующей сразу за <LF>), либо позиции, следующей сразу за любым «несловесным» символом. Следующий символ не обязательно должен быть «словом».

\>должно быть самый последний член в регулярном выражении. Регулярное выражение не будет соответствовать чему-либо, если за ним следуют другие символы. \>соответствует либо концу ввода, позиции непосредственно перед <CR>, либо позиции, непосредственно предшествующей любому «несловесному» символу. Предыдущий символ не обязательно должен быть символом «слово».

Вот полный список «несловесных» символов, представленных в виде десятичного байтового кода. Обратите внимание - этот список был составлен на американском компьютере. Я не знаю, какое влияние на этот список могут оказать другие языки.

001   028   063   179   204   230
002   029   064   180   205   231
003   030   091   181   206   232
004   031   092   182   207   233
005   032   093   183   208   234
006   033   094   184   209   235
007   034   096   185   210   236
008   035   123   186   211   237
009   036   124   187   212   238
011   037   125   188   213   239
012   038   126   189   214   240
014   039   127   190   215   241
015   040   155   191   216   242
016   041   156   192   217   243
017   042   157   193   218   244
018   043   158   194   219   245
019   044   168   195   220   246
020   045   169   196   221   247
021   046   170   197   222   248
022   047   173   198   223   249
023   058   174   199   224   250
024   059   175   200   226   251
025   060   176   201   227   254
026   061   177   202   228   255
027   062   178   203   229

Диапазоны классов символов Regex [xy]
Диапазоны классов символов не работают должным образом. Посмотрите на этот вопрос: почему findstr неправильно обрабатывает регистр (в некоторых случаях)? вместе с этим ответом: https://stackoverflow.com/a/8767815/1012053 .

Проблема в том, что FINDSTR не сопоставляет символы по значению их байтового кода (обычно считается кодом ASCII, но ASCII определяется только от 0x00 до 0x7F). Большинство реализаций регулярных выражений рассматривали бы [AZ] как все заглавные буквы английского алфавита. Но FINDSTR использует последовательность сортировки, которая примерно соответствует тому, как работает SORT. Таким образом, [AZ] включает полный английский алфавит, как в верхнем, так и в нижнем регистре (кроме «а»), а также неанглийские буквенные символы с диакритическими знаками.

Ниже приведен полный список всех символов, поддерживаемых FINDSTR, отсортированных в последовательности сопоставления, используемой FINDSTR для установления диапазонов классов символов регулярных выражений. Символы представлены в виде их десятичного значения байтового кода. Я считаю, что последовательность сортировки имеет смысл, если символы просматриваются с использованием кодовой страницы 437. Примечание. Этот список был составлен на компьютере США. Я не знаю, какое влияние на этот список могут оказать другие языки.

001
002
003
004
005
006
007
008
014
015
016
017
018           
019
020
021
022
023
024
025
026
027
028
029
030
031
127
039
045
032
255
009
010
011
012
013
033
034
035
036
037
038
040
041
042
044
046
047
058
059
063
064
091
092
093
094
095
096
123
124
125
126
173
168
155
156
157
158
043
249
060
061
062
241
174
175
246
251
239
247
240
243
242
169
244
245
254
196
205
179
186
218
213
214
201
191
184
183
187
192
212
211
200
217
190
189
188
195
198
199
204
180
181
182
185
194
209
210
203
193
207
208
202
197
216
215
206
223
220
221
222
219
176
177
178
170
248
230
250
048
172
171
049
050
253
051
052
053
054
055
056
057
236
097
065
166
160
133
131
132
142
134
143
145
146
098
066
099
067
135
128
100
068
101
069
130
144
138
136
137
102
070
159
103
071
104
072
105
073
161
141
140
139
106
074
107
075
108
076
109
077
110
252
078
164
165
111
079
167
162
149
147
148
153
112
080
113
081
114
082
115
083
225
116
084
117
085
163
151
150
129
154
118
086
119
087
120
088
121
089
152
122
090
224
226
235
238
233
227
229
228
231
237
232
234

Ограничение термина класса символов Regex и BUG
Мало того, что FINDSTR ограничен максимум 15 терминами класса символа в регулярном выражении, он не может должным образом обработать попытку превысить предел. Использование 16 или более символов класса символов приводит к появлению интерактивного всплывающего окна Windows с сообщением «Утилита Find String (QGREP) столкнулась с проблемой и должна быть закрыта. Приносим извинения за неудобства». Текст сообщения немного различается в зависимости от версии Windows. Вот один пример FINDSTR, который потерпит неудачу:

echo 01234567890123456|findstr [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]

Об этой ошибке сообщил пользователь DosTips Judago здесь . Это было подтверждено на XP, Vista и Windows 7.

Поиск по
регулярному выражению завершается ошибкой (и может зависать бесконечно), если он включает в себя байт-код 0xFF (десятичное число 255). Любой поиск по регулярному выражению, который включает байт-код 0xFF (десятичное число 255), завершится неудачей. Сбой, если байт-код 0xFF включен напрямую или неявно включен в диапазон классов символов. Помните, что диапазоны классов символов FINDSTR не сопоставляют символы на основе значения байтового кода. Характер <0xFF>появляется относительно рано в последовательности сопоставления между <space>и <tab>символами. Таким образом, любой диапазон классов персонажей, который включает и то <space>и другое <tab>, потерпит неудачу.

Точное поведение немного меняется в зависимости от версии Windows. Windows 7 зависает бесконечно, если включен 0xFF. XP не зависает, но всегда не может найти совпадение и иногда выдает следующее сообщение об ошибке: «Процесс пытался записать в несуществующий канал».

У меня больше нет доступа к машине с Vista, поэтому я не смог протестировать на Vista.

Ошибка.[^anySet]
регулярного выражения : и может соответствовать концу файла . Метасимвол регулярного выражения .должен соответствовать только любому символу, кроме <CR>или <LF>. Существует ошибка, которая позволяет ему соответствовать концу файла, если последняя строка в файле не заканчивается <CR>или <LF>. Однако, это .не будет соответствовать пустому файлу.

Например, файл с именем «test.txt», содержащий одну строку x, без завершения <CR>или <LF>, будет соответствовать следующему:

findstr /r x......... test.txt

Эта ошибка была подтверждена на XP и Win7.

То же самое можно сказать и о негативных наборах символов. Нечто подобное [^abc]будет соответствовать End-Of-File. Позитивные наборы символов вроде [abc]бы работают нормально. Я проверял это только на Win7.

findstr иногда неожиданно зависает при поиске больших файлов.

Я не подтвердил точные условия или размеры границ. Я подозреваю, что любой файл размером более 2 ГБ может быть в опасности.

У меня был смешанный опыт с этим, так что это больше, чем просто размер файла. Похоже, что это может быть разновидностью зависания FINDSTR в XP и Windows 7, если перенаправленный ввод не заканчивается LF , но, как показано, эта конкретная проблема проявляется, когда ввод не перенаправлен.

Следующий сеанс командной строки (Windows 7) демонстрирует, как findstrможет зависать при поиске файла 3 ГБ.

C:\Data\Temp\2014-04>echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890> T100B.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,10) do @type T100B.txt >> T1KB.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1KB.txt >> T1MB.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1MB.txt >> T1GB.txt

C:\Data\Temp\2014-04>echo find this line>> T1GB.txt

C:\Data\Temp\2014-04>copy T1GB.txt + T1GB.txt + T1GB.txt T3GB.txt
T1GB.txt
T1GB.txt
T1GB.txt
        1 file(s) copied.

C:\Data\Temp\2014-04>dir
 Volume in drive C has no label.
 Volume Serial Number is D2B2-FFDF

 Directory of C:\Data\Temp\2014-04

2014/04/08  04:28 PM    <DIR>          .
2014/04/08  04:28 PM    <DIR>          ..
2014/04/08  04:22 PM               102 T100B.txt
2014/04/08  04:28 PM     1 020 000 016 T1GB.txt
2014/04/08  04:23 PM             1 020 T1KB.txt
2014/04/08  04:23 PM         1 020 000 T1MB.txt
2014/04/08  04:29 PM     3 060 000 049 T3GB.txt
               5 File(s)  4 081 021 187 bytes
               2 Dir(s)  51 881 050 112 bytes free
C:\Data\Temp\2014-04>rem Findstr on the 1GB file does not hang

C:\Data\Temp\2014-04>findstr "this" T1GB.txt
find this line

C:\Data\Temp\2014-04>rem On the 3GB file, findstr hangs and must be aborted... even though it clearly reaches end of file

C:\Data\Temp\2014-04>findstr "this" T3GB.txt
find this line
find this line
find this line
^C
C:\Data\Temp\2014-04>

Обратите внимание, что в шестнадцатеричном редакторе я проверил, что все строки заканчиваются CRLF. Единственная аномалия в том, что файл завершается 0x1Aиз- за способа copyработы . Однако обратите внимание, что эта аномалия не вызывает проблем с «маленькими» файлами .

С дополнительным тестированием я подтвердил следующее:

• Использование copyс /bопцией для двоичных файлов предотвращает добавление 0x1Aсимвола и findstrне зависает на файле 3 ГБ.
• Завершение файла 3 ГБ другим символом также приводит findstrк зависанию.
• Символ 0x1Aне вызывает никаких проблем в «маленьком» файле. (Аналогично для других завершающих символов.)
• Добавление CRLFпосле 0x1Aрешает проблему. ( LFсамо по себе, вероятно, будет достаточно.)
• Использование typeдля передачи файла в findstrработу без зависания. (Это может быть связано с побочным эффектом одного typeили другого |дополнительного конца строки.)
• Использование перенаправленного ввода <также вызывает findstrзависание. Но это ожидается; как объяснено в посте dbenham : «перенаправленный ввод должен заканчиваться на LF» .

Когда несколько команд заключены в круглые скобки и файлы перенаправлены на весь блок:

< input.txt (
   command1
   command2
   . . .
) > output.txt

... тогда файлы остаются открытыми, пока команды в блоке активны, поэтому команды могут перемещать указатель файла перенаправленных файлов. Обе команды MORE и FIND перемещают указатель файла Stdin в начало файла перед его обработкой, поэтому один и тот же файл может обрабатываться несколько раз внутри блока. Например, этот код:

more < input.txt >  output.txt
more < input.txt >> output.txt

... произвести тот же результат, что и этот:

< input.txt (
   more
   more
) > output.txt

Этот код:

find    "search string" < input.txt > matchedLines.txt
find /V "search string" < input.txt > unmatchedLines.txt

... произвести тот же результат, что и этот:

< input.txt (
   find    "search string" > matchedLines.txt
   find /V "search string" > unmatchedLines.txt
)

FINDSTR отличается; он не перемещает указатель файла Stdin из его текущей позиции. Например, этот код вставляет новую строку после строки поиска:

call :ProcessFile < input.txt
goto :EOF

:ProcessFile
   rem Read the next line from Stdin and copy it
   set /P line=
   echo %line%
   rem Test if it is the search line
   if "%line%" neq "search line" goto ProcessFile
rem Insert the new line at this point
echo New line
rem And copy the rest of lines
findstr "^"
exit /B

Мы можем эффективно использовать эту функцию с помощью вспомогательной программы, которая позволяет нам перемещать указатель файла перенаправленного файла, как показано в этом примере .

Об этом поведении впервые сообщил Джеб на этом посту .

РЕДАКТИРОВАТЬ 2018-08-18 : сообщается о новой ошибке FINDSTR

У команды FINDSTR есть странная ошибка, которая возникает, когда эта команда используется для отображения символов в цвете И выходные данные такой команды перенаправляются на устройство CON. Подробнее о том, как использовать команду FINDSTR для отображения текста в цвете, см. Этот раздел .

Когда вывод этой формы команды FINDSTR перенаправляется на CON, происходит нечто странное после того, как текст выводится в желаемом цвете: весь текст после него выводится в виде «невидимых» символов, хотя более точное описание состоит в том, что текст вывод в виде черного текста на черном фоне. Исходный текст появится, если вы используете команду COLOR для сброса цветов переднего плана и фона всего экрана. Однако, когда текст «невидим», мы можем выполнить команду SET / P, поэтому все введенные символы не будут отображаться на экране. Такое поведение может быть использовано для ввода паролей.

@echo off
setlocal

set /P "=_" < NUL > "Enter password"
findstr /A:1E /V "^$" "Enter password" NUL > CON
del "Enter password"
set /P "password="
cls
color 07
echo The password read is: "%password%"

Я хотел бы сообщить об ошибке в разделе « Источник данных» для поиска в первом ответе при использовании en dash (-) или em dash (-) в имени файла.

Более конкретно, если вы собираетесь использовать первый вариант - имена файлов, указанные в качестве аргументов , файл не будет найден. Как только вы используете опцию 2 - stdin через перенаправление или 3 - поток данных из канала , findstr найдет файл.

Например, этот простой пакетный скрипт:

echo off
chcp 1250 > nul
set INTEXTFILE1=filename with – dash.txt
set INTEXTFILE2=filename with — dash.txt

rem 3 way of findstr use with en dashed filename
echo.
echo Filename with en dash:
echo.
echo 1. As argument
findstr . "%INTEXTFILE1%"
echo.
echo 2. As stdin via redirection
findstr . < "%INTEXTFILE1%"
echo.
echo 3. As datastream from a pipe
type "%INTEXTFILE1%" | findstr .
echo.
echo.
rem The same set of operations with em dashed filename
echo Filename with em dash:
echo.
echo 1. As argument
findstr . "%INTEXTFILE2%"
echo.
echo 2. As stdin via redirection
findstr . < "%INTEXTFILE2%"
echo.
echo 3. As datastream from a pipe
type "%INTEXTFILE2%" | findstr .
echo.

pause

напечатает:

Имя файла с тире:

1. В качестве аргумента
   FINDSTR: Невозможно открыть имя файла с - dash.txt

2. Как STDIN через перенаправление,
   я файл с черточкой.

3. Как поток данных из трубы,
   я файл с черточкой.

Имя файла с em dash:

1. В качестве аргумента
   FINDSTR: Невозможно открыть имя файла с - dash.txt

2. Как STDIN через перенаправление
   я файл с тире.

3. Как поток данных из канала,
   я являюсь файлом с тире.

Надеюсь, поможет.

М.

findstrКоманда устанавливает ErrorLevel(или код выхода) к одному из следующих значений, учитывая , что нет никаких недействительных или несовместимых выключателей и не строка поиска не превышает предельное значение длины:

• 0 когда хотя бы одно совпадение встречается в одной строке во всех указанных файлах;
• 1 в противном случае;

Считается, что строка содержит совпадение, если:

• не /Vзадана опция и выражение поиск происходит по крайней мере один раз;
• /Vзадана опция и выражение поиска не происходит;

Это означает, что /Vопция также изменяет возвращаемое значение ErrorLevel, но не просто возвращает его!

Например, если у вас есть файл test.txtс двумя линиями, одна из которых содержит строку , textа другой нет, как findstr "text" "test.txt"и findstr /V "text" "test.txt"возвращать ErrorLevelиз 0.

По сути, вы можете сказать: если findstrвозвращается хотя бы строка, ErrorLevelустанавливается значение 0, иначе - 1.

Обратите внимание, что /Mпараметр не влияет на ErrorLevelзначение, он просто изменяет вывод.

(Просто ради полноты: findкоманда ведет себя точно так же по отношению к /Vопции и ErrorLevel; /Cопция не влияет ErrorLevel.)

У FINDSTR есть ошибка цвета, которую я описал и решил по адресу /superuser/1535810/is-there-a-better-way-to-mitigate-this-obscure-color-bug-when-piping-to -findstr / 1538802? noredirect = 1 # comment2339443_1538802

Подводя итог, можно сказать, что ошибка заключается в том, что если входные данные передаются в FINDSTR в заключенном в скобки блоке кода, встроенные экранирующие цветовые коды ANSI перестают работать в командах, выполняемых позже. Пример встроенных цветовых кодов: echo %magenta%Alert: Something bad happened%yellow%(где пурпурный и желтый - переменные, определенные ранее в файле .bat как соответствующие escape-коды ANSI).

Моим первоначальным решением было вызвать подпрограмму «ничего не делать» после FINDSTR. Каким-то образом вызов или возврат «сбрасывает» все, что необходимо сбросить.

Позже я обнаружил другое решение, которое предположительно является более эффективным: поместите фразу FINDSTR в скобки, как показано в следующем примере: echo success | ( FINDSTR /R success ) размещение фразы FINDSTR во вложенном блоке кода, по-видимому, изолирует ошибку цветового кода FINDSTR, поэтому она не влияет на то, что находится за пределами вложенного блок. Возможно, этот метод решит и некоторые другие нежелательные побочные эффекты FINDSTR .

/ D совет для нескольких каталогов: поместите ваш список каталогов перед строкой поиска. Это все работает:

findstr /D:dir1;dir2 "searchString" *.*
findstr /D:"dir1;dir2" "searchString" *.*
findstr /D:"\path\dir1\;\path\dir2\" "searchString" *.*

Как и ожидалось, путь относительно местоположения, если вы не начинаете каталоги с \. Обводить путь с помощью "необязательно, если в именах каталогов нет пробелов. Окончание не \является обязательным. Вывод местоположения будет включать в себя любой путь, который вы дадите. Он будет работать с или без окружения списка каталогов ".