Jakie są nieudokumentowane funkcje i ograniczenia polecenia Windows FINDSTR?

Question

Jakie są nieudokumentowane funkcje i ograniczenia polecenia Windows FINDSTR?

Polecenie Windows FINDSTR jest strasznie udokumentowane. Istnieje bardzo podstawowa pomoc wiersza poleceń dostępna za pośrednictwem FINDSTR /? LUB HELP FINDSTR, ale jest ona żałośnie niewystarczająca. Jest trochę więcej dokumentacji w Internecie na https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr.

Istnieje wiele funkcji i ograniczeń FINDSTR, o których nawet nie wspomniano w dokumentacji. Nie można ich też było przewidzieć bez uprzedniej wiedzy i / lub staranności eksperymenty.

Więc pytanie brzmi - jakie są nieudokumentowane funkcje i ograniczenia FINDSTR?

Celem tego pytania jest zapewnienie jednego repozytorium wielu nieudokumentowanych funkcji, tak aby:

A) programiści mogą w pełni korzystać z dostępnych funkcji.

B) deweloperzy nie tracą czasu na zastanawianie się, dlaczego coś nie działa, kiedy wydaje się, że powinno.

Upewnij się, że znasz istniejącą dokumentację zanim odpowiesz. Jeśli informacje są objęte pomocą, to nie należy tutaj.

Nie jest to również miejsce do pokazania ciekawych zastosowań FINDSTR. Jeśli logiczna osoba może przewidzieć zachowanie określonego użycia FINDSTR na podstawie dokumentacji, to nie należy tutaj.

Podobnie, jeśli logiczna osoba mogłaby przewidzieć zachowanie określonego użycia w oparciu o informacje zawarte w istniejących odpowiedziach, to ponownie nie należy do nich proszę.

168

batch-file cmd findstr

Author: dbenham, 2012-01-13

Source

6 answers

odpowiedź ciąg dalszy z części 1 powyżej - przekroczyłem limit odpowiedzi 30 000 znaków :-(

Obsługa ograniczonych wyrażeń regularnych (regex)
Obsługa FINDSTR dla wyrażeń regularnych jest bardzo ograniczona. Jeśli nie ma go w dokumentacji pomocy, nie jest obsługiwany.

Poza tym, wyrażenia regex, które są obsługiwane są zaimplementowane w całkowicie niestandardowy sposób, tak że wyniki mogą być różne wtedy można się spodziewać pochodzi z czegoś takiego jak grep czy perl.

Kotwice pozycji linii Regex ^ i $
^ dopasowuje początek strumienia wejściowego, jak również dowolną pozycję bezpośrednio po . Ponieważ FINDSTR również łamie linie po , proste wyrażenie regularne " ^ " zawsze będzie pasowało do wszystkich linii w pliku, nawet pliku binarnego.

$ pasuje do dowolnej pozycji bezpośrednio poprzedzającej & LT; CR>. Oznacza to, że szukany ciąg regex zawierający $ nigdy nie będzie pasował do żadnych linii w systemie Unix styl pliku tekstowego, ani nie będzie pasował do ostatniej linii pliku tekstowego Windows, jeśli brakuje mu znacznika EOL .

Uwaga - jak wcześniej omówiono, przekierowane i przekierowane dane wejściowe do FINDSTR mogą mieć dołączoną <CR><LF>, której nie ma w źródle. Oczywiście może to mieć wpływ na wyszukiwanie regex, które używa $.

Każdy szukany ciąg znaków przed ^ lub po $ zawsze nie znajdzie dopasowania.

Opcje Pozycyjne / B / E / X
Na opcje pozycyjne działają tak samo jak ^ i $, z tym że działają również dla literalnych ciągów wyszukiwania.

/B działa tak samo jak ^ na początku szukanego ciągu regex.

/ E działa tak samo jak $ na końcu ciągu wyszukiwania regex.

/x działa tak samo jak ^ na początku i $ na końcu ciągu wyszukiwania regex.

Regex Word boundary
\< to musi być pierwszy termin w regex. Regex nie będzie pasować do niczego, jeśli jakiekolwiek inne znaki poprzedzają to. \< odpowiada albo początkowi wejścia, początkowi linii (pozycja bezpośrednio po ), albo pozycji bezpośrednio po dowolnym znaku "nie-wyrazowym". Następny znak nie musi być znakiem "słowo".

\> to musi być ostatni termin w regex. Wyrażenie regularne nie będzie pasować do niczego, jeśli podążą za nim inne znaki. \> odpowiada albo końcowi wejścia, pozycji bezpośrednio przed lub pozycją bezpośrednio poprzedzającą dowolny znak "nie-wyrazowy". Poprzedzający znak nie musi być znakiem "słowo".

Oto pełna lista znaków "nie-słownych", reprezentowanych jako kod dziesiętny. Uwaga-Ta lista została skompilowana na maszynie U. S. Nie wiem, jaki wpływ na tę listę mogą mieć inne języki.

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

Zakresy klas znaków Regex [x-y]
Zakresy klas znaków nie działają zgodnie z oczekiwaniami. Zobacz to pytanie: dlaczego findstr nie obsługuje poprawnie case (w pewnych okolicznościach)?, wraz z tą odpowiedzią: https://stackoverflow.com/a/8767815/1012053 .

Problem polega na tym, że FINDSTR nie zestawia znaków według ich wartości kodu bajtowego (powszechnie uważanego za kod ASCII, ale ASCII jest zdefiniowane tylko od 0x00 - 0x7f). Większość implementacji regex traktowałaby [A-Z] jako wszystkie wielkie litery angielskie. Ale FINDSTR używa sekwencji zestawiania, która z grubsza odpowiada działaniu sortowania. Tak więc [A-Z] zawiera kompletny alfabet angielski, zarówno wielkie i małe litery (z wyjątkiem "a"), jak i nie-angielskie znaki Alfa ze znakami diakrytycznymi.

Poniżej znajduje się pełna lista wszystkich znaków obsługiwanych przez FINDSTR, posortowanych w sekwencji sortowania używanej przez FINDSTR do określania zakresów klas znaków regex. Znaki są reprezentowane jako ich wartość dziesiętnego kodu bajtowego. Uważam, że kolejność zestawiania ma największy sens, jeśli znaki są Wyświetlono 437 razy. Uwaga-Ta lista została skompilowana na maszynie U. S. Nie wiem, jaki wpływ na tę listę mogą mieć inne języki.

Regex character class term limit i BUG
FINDSTR nie tylko ogranicza się do maksymalnie 15 znaków klasowych w ramach wyrażenia regularnego, ale nie obsługuje poprawnie próby przekroczenia limitu. Użycie 16 lub więcej terminów klas znaków powoduje wyświetlenie interaktywnego okna z napisem " Find String (QGREP) Narzędzie napotkało problem i musi się zamknąć. Przepraszamy za niedogodności." tekst wiadomości różni się nieznacznie w zależności od wersji systemu Windows. Oto jeden przykład FINDSTR, który się nie powiedzie:

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]

Ten błąd został zgłoszony przez użytkownika Dostips Judago tutaj . Został on potwierdzony NA XP, Vista i Windows 7.

Wyszukiwanie Regularne nie powiedzie się (i może wisieć w nieskończoność), jeśli zawierają kod bajtowy 0xFF (dziesiętny 255)
Każde wyszukiwanie regex, które zawiera kod bajtowy 0xFF (dziesiętny 255) nie powiedzie się. Nie powiedzie się, jeśli kod bajtowy 0xFF jest dołączony bezpośrednio lub jeśli jest niejawnie zawarty w zakresie klas znaków. Pamiętaj, że zakresy klas znaków FINDSTR nie kompilują znaków na podstawie wartości kodu bajtowego. Znak <0xFF> pojawia się stosunkowo wcześnie w sekwencji zestawiania między znakami <space> i <tab>. Tak więc każdy zakres klas znaków zawierający zarówno <space>, jak i <tab> zakończy się niepowodzeniem.

Dokładne zachowanie zmienia się nieznacznie w zależności od wersji systemu Windows. Windows 7 zawiesza się na czas nieokreślony, jeśli zawiera 0xFF. XP nie zawiesza się, ale zawsze nie znajduje dopasowania i czasami wypisuje następujący komunikat o błędzie - " proces próbował napisać do nieistniejącego potoku."

Nie mam już dostępu do maszyny Vista, więc nie byłem w stanie przetestować Na Vista.

Błąd Regex: . i [^anySet] może dopasować koniec pliku
Meta-znak regex . powinien pasować tylko do dowolnego znak inny niż <CR> lub <LF>. Istnieje błąd, który pozwala mu dopasować koniec pliku, jeśli ostatnia linia w pliku nie jest zakończona przez <CR> lub <LF>. Jednak . nie będzie pasował do pustego pliku.

Na przykład plik o nazwie "test.txt " zawierający pojedynczy wiersz x, bez zakończenia <CR> lub <LF>, będzie pasował do:

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

Ten błąd został potwierdzony NA XP i Win7.

To samo wydaje się być prawdziwe dla ujemnych zestawów znaków. Coś w rodzaju [^abc] będzie pasowało do końca pliku. Pozytywne zestawy znaków, takie jak [abc], wydają się działać dobrze. Testowałem to tylko na Win7.

57

Author: dbenham,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:34:59

findstr Czasami nieoczekiwanie zawiesza się podczas wyszukiwania dużych plików.

Nie potwierdziłem dokładnych warunków ani wielkości granic. Podejrzewam, że każdy plik większy 2GB może być zagrożony.

Miałem z tym mieszane doświadczenia, więc jest to coś więcej niż tylko Rozmiar pliku. Wygląda na to, że może to być wariacja na FINDSTR zawiesza się na XP i Windows 7, jeśli przekierowane wejście nie kończy się na LF, ale jak wykazano, ten konkretny problem objawia się, gdy wejście jest , a nie Przekierowano.

Następująca sesja wiersza poleceń (Windows 7) pokazuje, jak findstr może się zawiesić podczas wyszukiwania Pliku 3GB.

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>

Uwaga, zweryfikowałem w edytorze szesnastkowym, że wszystkie linie są zakończone CRLF. Jedyną anomalią jest to, że plik jest zakończony 0x1A ze względu na sposób działania copy . Zauważ jednak, że owa anomalia nie powoduje problemu na "małych" plikach.

Z dodatkowymi badaniami potwierdziłem po:

użycie copy z opcją /b dla plików binarnych zapobiega dodaniu znaku 0x1A, A findstr nie zawiesza się na pliku 3GB.
Zamknięcie pliku 3GB innym znakiem powoduje również zawieszenie findstr.
znak 0x1A nie powoduje żadnych problemów na "małym" pliku. (Podobnie dla innych znaków kończących.)
dodanie CRLF Po 0x1A rozwiązuje problem. (LF sama w sobie prawdopodobnie wystarczy.)
użycie type do przekierowania pliku do findstr działa bez zawieszania. (Może to być spowodowane działaniem ubocznym type lub |, które wstawia dodatkowy koniec linii.)
użycie przekierowanego wejścia < powoduje również zawieszenie findstr. ale to jest oczekiwane; jak wyjaśniono w dbenham post: "przekierowane wejście musi kończyć się LF".

5

Author: Disillusioned,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:10:54

Gdy kilka poleceń jest zamkniętych w nawiasach i są przekierowywane pliki do całego bloku:

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

... następnie pliki pozostają otwarte tak długo, jak polecenia w bloku są aktywne, więc polecenia mogą przenosić wskaźnik pliku przekierowanych plików. Zarówno polecenia MORE, jak I FIND przenoszą wskaźnik pliku Stdin na początek pliku przed przetworzeniem go, więc ten sam plik może być przetworzony kilka razy wewnątrz bloku. Na przykład ten kod:

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

... produce ten sam wynik niż ten:

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

Ten kod:

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

... uzyskaj ten sam wynik niż ten:

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

FINDSTR jest inny; nie przesuwa wskaźnik pliku Stdin z jego bieżącej pozycji. Na przykład ten kod wstawia nową linię po linii wyszukiwania:

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

Możemy dobrze wykorzystać tę funkcję za pomocą programu pomocniczego, który pozwala nam przenieść wskaźnik pliku przekierowanego pliku, Jak pokazano w this przykład .

To zachowanie zostało po raz pierwszy zgłoszone przez jeb w ten post.

Edytuj 2018-08-18: zgłoszono nowy błąd FINDSTR

Polecenie FINDSTR ma dziwny błąd, który zdarza się, gdy to polecenie jest używane do wyświetlania znaków w Kolorze, A wyjście takiego polecenia jest przekierowywane do urządzenia CON. Aby dowiedzieć się więcej o tym, jak używać polecenia FINDSTR do wyświetlania tekstu w Kolorze, zobacz ten temat.

Gdy wyjście tej postaci Polecenie FINDSTR jest przekierowywane do CON, coś dziwnego dzieje się po wyświetleniu tekstu w pożądanym kolorze: cały tekst po wyświetleniu jako" niewidoczne " znaki, chociaż bardziej precyzyjny opis jest taki, że tekst jest wyświetlany jako czarny tekst na czarnym tle. Oryginalny tekst pojawi się, jeśli użyjesz polecenia kolor, aby zresetować kolory pierwszego planu i tła całego ekranu. Jednak gdy tekst jest "niewidoczny" możemy wykonać polecenie SET / P, więc wszystkie wprowadzone znaki będą nie pojawiają się na ekranie. To zachowanie może być używane do wprowadzania haseł.

@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%"

5

Author: Aacini,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-08-19 02:13:31

Chciałbym zgłosić błąd dotyczący sekcji źródła danych do wyszukiwania w pierwszej odpowiedzi przy użyciu en dash ( – ) lub em dash ( - ) wewnątrz nazwy pliku.

Dokładniej, jeśli masz zamiar użyć pierwszej opcji- nazwy plików określone jako argumenty, plik nie zostanie znaleziony. Gdy tylko użyjesz opcji 2 - stdin poprzez przekierowanie lub 3 - strumień danych z rury, findstr znajdzie plik.

Na przykład, to prosty skrypt wsadowy:

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

Wydrukuje:

Nazwa pliku z myślnikiem en:

Jako argument
FINDSTR: nie można otworzyć nazwy pliku za pomocą - dash.txt
Jako stdin poprzez przekierowanie
/ align = "left" /
Jako strumień danych z rury
/ align = "left" /

Nazwa pliku z myślnikiem em:

Jako argument
FINDSTR: nie można otworzyć nazwy pliku z - dash.txt
Jako stdin poprzez przekierowanie
/ align = "left" /
Jako strumień danych z rury
/ align = "left" /

Mam nadzieję, że to pomoże.

M.

2

Author: matro,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-18 17:25:03

/ d wskazówka dla wielu katalogów: umieść listę katalogów przed szukanym ciągiem. Wszystkie działają:

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

Zgodnie z oczekiwaniami, ścieżka jest względem lokalizacji, jeśli nie rozpoczynasz katalogów od \. Otaczanie ścieżki " jest opcjonalne, jeśli w nazwach katalogów nie ma spacji. Zakończenie \ jest opcjonalne. Wynik lokalizacji będzie zawierał dowolną ścieżkę, którą mu podasz. Będzie działać z listą katalogów lub bez niej za pomocą ".

-1

Author: gordon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-22 20:11:26

score 257 · Accepted Answer

Przedmowa
większość informacji zawartych w tej odpowiedzi została zebrana w oparciu o eksperymenty prowadzone na maszynie Vista. O ile wyraźnie nie zaznaczono inaczej, nie potwierdziłem, czy informacje dotyczą innych wersji systemu Windows.

FINDSTR output
Dokumentacja nigdy nie przeszkadza wyjaśnić wyjście FINDSTR. Nawiązuje to do faktu, że pasujące linie są drukowane, ale nic więcej.

The format dopasowanego wiersza wyjściowego jest następujący:

nazwa pliku: lineNumber: lineOffset: text

Gdzie

nazwa pliku: = nazwa pliku zawierającego pasującą linię. Nazwa pliku nie jest drukowana, jeśli żądanie było jawnie dla pojedynczego pliku, lub jeśli szukano piped input lub przekierowanego input. Po wydrukowaniu nazwa pliku zawsze będzie zawierać informacje o podanej ścieżce. Dodatkowe informacje o ścieżce zostaną dodane jeśli używana jest opcja /S. Drukowana ścieżka jest zawsze względem podanej ścieżki lub względem bieżącego katalogu, jeśli nie podano.

Uwaga-prefiks nazwy pliku można uniknąć podczas przeszukiwania wielu plików za pomocą niestandardowych (i słabo udokumentowanych) symboli wieloznacznych < i >. Dokładne zasady działania tych symboli wieloznacznych można znaleźć tutaj . Na koniec, możesz spojrzeć na ten przykład jak niestandardowe symbole wieloznaczne działają z FINDSTR .

/ align = "left" / linear: = numer wiersza pasującego wiersza reprezentowany jako wartość dziesiętna, przy czym 1 reprezentuje 1. wiersz wejścia. Drukowane tylko wtedy, gdy podano opcję /N.

lineOffset: = przesunięcie bajtów dziesiętnych początku pasującego wiersza, przy czym 0 oznacza 1. znak 1. wiersza. Drukowane tylko wtedy, gdy podano opcję /O. To jest nie przesunięcie meczu w linii. Chodzi o ilość bajtów od początku pliku do początku linii.

tekst = binarna reprezentacja pasującej linii, w tym dowolne &LT; CR > i / lub & LT;LF>. Nic nie zostanie pominięte z wyjścia binarnego, tak że ten przykład, który pasuje do wszystkich linii, wytworzy dokładną kopię binarną oryginalnego pliku.

FINDSTR "^" FILE >FILE_COPY

Większość znaków sterujących i wiele rozszerzonych znaków ASCII wyświetla się jako kropki na XP
FINDSTR na XP wyświetla większość niedrukowalnych znaków sterujących z pasujących linii jako kropki (kropki) na ekranie. Wyjątkami są następujące znaki sterujące: 0x09 Tab, 0x0A LineFeed, 0x0b Vertical Tab, 0x0c Form Feed, 0x0d Carriage Return.

XP FINDSTR konwertuje również wiele rozszerzonych znaków ASCII na kropki. Rozszerzone znaki ASCII wyświetlane jako kropki na XP są takie same jak te, które są przekształcane po dostarczeniu w wierszu poleceń. Zobacz sekcję "limity znaków dla parametrów wiersza poleceń-Rozszerzona transformacja ASCII" , później w tym poście

Znaki sterujące i rozszerzone ASCII nie są konwertowane na kropki w XP, JEŚLI wyjście jest przekierowane do pliku lub w klauzuli FOR IN ().

Vista i Windows 7 zawsze wyświetlają wszystkie znaki jako siebie, nigdy jako kropki.

Kody zwrotne (ERRORLEVEL)

0 (sukces)
- dopasowanie zostało znalezione w co najmniej jednej linii co najmniej jednego pliku.
1 (awaria)
- nie znaleziono dopasowania w żadnej linii żadnego pliku.
- nieprawidłowy kolor określony przez opcję /A:xx
2 (Błąd)
- niezgodne opcje /L i /R zarówno określone
- brak argumentu po /A:, /F:, /C:, /D:, lub /G:
- plik określony przez /F:file lub /G:file Nie znaleziono
255 (błąd)
- zbyt wiele wyrażeń regularnych
  zobacz regex character class term limit i BUG w części 2 odpowiedzi

Źródło danych do wyszukiwania (aktualizacja na podstawie testów z systemem Windows 7)
Findstr może wyszukiwać dane tylko z jednego z następujących źródeł:

Nazwy plików podane jako argumenty i / lub za pomocą opcji /F:file.
Stdin przez przekierowanie findstr "searchString" <file
Strumień danych z rury type file | findstr "searchString"

Argumenty/opcje mają pierwszeństwo przed przekierowaniem, które ma pierwszeństwo przed danymi rurociągowymi.

Argumenty nazw plików i /F:file mogą być łączone. Można użyć wielu argumentów nazwy pliku. Jeśli podano wiele opcji /F:file, to używana jest tylko ostatnia. Dzikie karty są dozwolone w argumentach nazw plików, ale Nie w pliku wskazywanym przez /F:file.

Źródło ciągów wyszukiwania (aktualizacja na podstawie testów z systemem Windows 7)
Opcje /G:file i /C:string mogą być łączone. Można podać wiele opcji /C:string. Jeśli podano wiele opcji /G:file, to używana jest tylko ostatnia. Jeśli użyto /G:file lub /C:string, to wszystkie argumenty nie będące opcjami są plikami do przeszukiwania. Jeśli nie użyto ani /G:file ani /C:string, To pierwszym argumentem nie będącym opcją jest traktowana jako rozdzielona spacją lista wyszukiwanych terminów.

Nazwy plików nie mogą być cytowane w pliku przy użyciu opcji /F:FILE.
Nazwy plików mogą zawierać spacje i inne znaki specjalne. Większość poleceń wymaga, aby takie nazwy plików były cytowane. Ale opcja FINDSTR /F:files.txt wymaga, aby nazwy plików w plikach.txt nie może być cytowany. Plik nie zostanie znaleziony, jeśli nazwa jest zacytowana.

Błąd-krótkie nazwy plików 8.3 mogą złamać /D i /S opcje
Podobnie jak w przypadku wszystkich poleceń systemu Windows, FINDSTR spróbuje dopasować zarówno długą nazwę, jak i krótką nazwę 8.3 podczas wyszukiwania plików do przeszukiwania. Załóżmy, że bieżący folder zawiera następujące niepuste pliki:

b1.txt
b.txt2
c.txt

Następujące polecenie z powodzeniem odnajdzie wszystkie 3 pliki:

findstr /m "^" *.txt

b.txt2 pasuje, ponieważ odpowiednia krótka nazwa B9F64~1.TXT pasuje. Jest to zgodne z zachowaniem wszystkich innych poleceń systemu Windows.

Ale bug z /D i /S opcje powodują, że następujące polecenia znajdują tylko b1.txt

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

Błąd uniemożliwia odnalezienie b.txt2, a także wszystkich nazw plików sortowanych po b.txt2 w tym samym katalogu. Znaleziono dodatkowe pliki, które wcześniej sortowały, jak a.txt. Dodatkowe pliki, które zostaną później sortowane, takie jak d.txt, są pomijane po wywołaniu błędu.

Każdy wyszukiwany katalog jest traktowany niezależnie. Na przykład, opcja /S z powodzeniem rozpocznie wyszukiwanie w folderze potomnym po nieudanym znalezieniu plików w rodzicu, ale gdy błąd spowoduje pominięcie krótkiej nazwy pliku w folderze potomnym, wszystkie kolejne pliki w tym folderze potomnym również zostaną pominięte.

Polecenia działają bez błędów, jeśli te same nazwy plików są tworzone na komputerze, który ma wyłączoną generację nazw NTFS 8.3. Oczywiście b.txt2 nie zostanie znaleziony, ale c.txt zostanie znaleziony prawidłowo.

Nie wszystkie krótkie nazwy wywołują błąd. Wszystkie przypadki podsłuchów jakie mam seen obejmują rozszerzenie, które jest dłuższe niż 3 znaki z krótką nazwą 8.3, która zaczyna się tak samo jak normalna nazwa, która nie wymaga nazwy 8.3.

Błąd został potwierdzony w XP, Vista i Windows 7.

Znaki niedrukowalne i opcja /P
Opcja /P powoduje, że FINDSTR pomija dowolny plik zawierający dowolny z następujących kodów dziesiętnych:
0-7, 14-25, 27-31.

Mówiąc inaczej, opcja /P będzie tylko pomiń pliki, które zawierają niedrukowalne znaki sterujące. Znaki kontrolne to kody mniejsze lub równe 31 (0x1F). FINDSTR traktuje następujące znaki sterujące jako drukowalne:

 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)

Wszystkie pozostałe znaki sterujące są traktowane jako niedrukowalne, których obecność powoduje pominięcie pliku przez opcję /P.

Dane wejściowe mogą mieć <CR><LF> dołączone
Jeśli wejście jest wyprowadzone, a ostatnim znakiem strumienia nie jest <LF>, to FINDSTR automatycznie doda <CR><LF> do wejścia. Zostało to potwierdzone na XP, Vista i Windows 7. (kiedyś myślałem, że rura systemu Windows jest odpowiedzialna za modyfikację danych wejściowych, ale od tego czasu odkryłem, że FINDSTR faktycznie dokonuje modyfikacji.)

To samo dotyczy przekierowanego wejścia na Vista. Jeśli ostatnim znakiem pliku używanego jako przekierowane wejście nie jest <LF>, FINDSTR automatycznie doda <CR><LF> do wejścia. Jednak XP i Windows 7 nie zmieniaj przekierowanego wejścia.

FINDSTR zawiesza się na XP i Windows 7, jeśli przekierowane wejście nie kończy się na <LF>
Jest to paskudna "funkcja" Na XP i Windows 7. Jeśli ostatni znak pliku używanego jako przekierowane wejście nie kończy się na <LF>, FINDSTR zawiesi się na czas nieokreślony, gdy dotrze do końca przekierowanego pliku.

Ostatni wiersz Piped data może być ignorowany, jeśli składa się z pojedynczego znaku
Jeśli wejście jest umieszczone w ostatni wiersz składa się z pojedynczego znaku, po którym nie następuje <LF>, A FINDSTR całkowicie ignoruje ostatni wiersz.

Przykład-pierwsze polecenie z pojedynczym znakiem i nie <LF> nie pasuje, ale drugie polecenie z 2 Znakami działa dobrze, podobnie jak trzecie polecenie, które ma jeden znak z zakończeniem nowej linii.

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

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

> echo x| findstr "^"
x

Zgłoszone przez użytkownika DosTips Sponge Belly na nowy błąd findstr. Potwierdzone na XP, Windows 7 i Windows 8. Haven ' t słyszałem już o Vistie. (Nie Mam już Visty do testowania).

Składnia opcji
Opcje mogą być poprzedzone przez / lub - Opcje mogą być łączone po pojedynczym / lub -. Jednak skonkatenowana lista opcji może zawierać co najwyżej jedną opcję wieloznakową, taką jak OFF lub F:, A opcja wieloznakowa musi być ostatnią opcją na liście.

Poniżej przedstawiono wszystkie równoważne sposoby wyrażania przeszukiwania regex niewrażliwego na wielkość liter dla dowolnego linia, która zawiera zarówno "hello" jak i "goodbye" w dowolnej kolejności

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

Limity długości łańcucha wyszukiwania
W systemie Vista maksymalna dozwolona długość pojedynczego ciągu Wyszukiwania wynosi 511 bajtów. Jeśli szukany ciąg przekracza 511, wynikiem jest błąd FINDSTR: Search string too long. Z ERRORLEVEL 2.

Podczas wyszukiwania wyrażeń regularnych, maksymalny ciąg wyszukiwania długość 254. Wyrażenie regularne o długości od 255 do 511 spowoduje błąd FINDSTR: Out of memory z poziomem błędu 2. Długość wyrażenia regularnego > 511 powoduje błąd FINDSTR: Search string too long..

W systemie Windows XP długość ciągu Wyszukiwania jest najwyraźniej krótsza. błąd Findstr: "zbyt długi ciąg wyszukiwania" : Jak wyodrębnić i dopasować podłańcuch w pętli "for"? Limit XP wynosi 127 bajtów dla wyszukiwania dosłownego i regex.

Granice długości linii
Pliki określone jako argument wiersza poleceń lub za pomocą opcji / f: FILE nie ma znanego limitu długości wiersza. Wyszukiwanie zostało pomyślnie przeprowadzone w przypadku pliku 128MB, który nie zawierał pojedynczego .

Przesyłane dane i przekierowane dane wejściowe są ograniczone do 8191 bajtów na linię. Ten limit jest "funkcją" FINDSTR. Nie jest to nieodłączne dla rur lub przekierowania. FINDSTR używając przekierowanego wejścia stdin lub piped nigdy nie będzie pasował do żadnej linii, która jest > = 8K bajtów. Lines > = 8K generuje komunikat o błędzie na stderr, ale ERRORLEVEL jest nadal 0, jeśli szukany ciąg zostanie znaleziony w co najmniej jednej linii co najmniej jednego pliku.

Domyślny typ wyszukiwania: Literal vs Wyrażenie regularne
/C:"string" - domyślną wartością jest literał / L. Jawne połączenie opcji /L z /C: "string" z pewnością działa, ale jest zbędne.

"string argument" - wartość domyślna zależy od zawartości pierwszego szukanego ciągu. (pamiętaj, że służy do rozdzielania ciągów wyszukiwania.) jeśli pierwszy ciąg wyszukiwania jest poprawny Wyrażenie regularne, które zawiera co najmniej jeden meta-znak, a następnie wszystkie wyszukiwane ciągi są traktowane jako wyrażenia regularne. W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jako literały. Na przykład "51.4 200" będzie traktowane jako dwa wyrażenia regularne, ponieważ pierwszy łańcuch zawiera kropkę, której nie udało się uniknąć, natomiast "200 51.4" będzie traktowany jako dwa literały, ponieważ pierwszy łańcuch nie zawiera żadnych meta-znaków.

/G:file - wartość domyślna zależy od zawartości pierwszego niepustego linia w pliku. Jeśli pierwszy wyszukiwany ciąg znaków jest poprawnym wyrażeniem regularnym, które zawiera co najmniej jeden meta-znak, który nie został zabezpieczony, to wszystkie wyszukiwane ciągi znaków są traktowane jako wyrażenia regularne. W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jako literały.

rekomendacja - zawsze jawnie określaj opcję /L literal lub /R Wyrażenie regularne, gdy używasz "string argument" lub /G:file.

Błąd-podanie wielu literalnych ciągów wyszukiwania może dać zawodne wyniki

Poniższy prosty przykład FINDSTR nie znajduje dopasowania, mimo że powinien.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

Ten błąd został potwierdzony na Windows Server 2003, Windows XP, Vista i Windows 7.

Na podstawie eksperymentów FINDSTR może się nie udać, jeśli spełnione są wszystkie następujące warunki:]}

wyszukiwanie odbywa się za pomocą wielu literalnych ciągów wyszukiwania
ciągi wyszukiwania są różnej długości
krótki ciąg wyszukiwania ma niektóre nakładają się na dłuższy ciąg wyszukiwania

W każdej porażce, jaką widziałem, zawsze jest to jeden z krótszych ciągów wyszukiwania, który zawodzi.

Aby uzyskać więcej informacji zobacz dlaczego ten przykład FINDSTR z wieloma literalnymi ciągami wyszukiwania nie znajduje dopasowania?

cudzysłowy i odwrotne ukośniki w argumentach wiersza poleceń-Uwaga:
Informacje w tej podświetlonej sekcji nie jest w 100% dokładne. Po napisaniu tej sekcji, użytkownik MC ND wskazał mi odniesienie dokumentuje sposób parsowania biblioteki Microsoft C / C++ parametry . Jest to przerażająco skomplikowane, ale wydaje się, że dokładnie przewidzieć reguły odwrotnego ukośnika i cudzysłowu dla argumentów linii poleceń FINDSTR. I polecam skorzystanie z podświetlonych informacji poniżej jako przewodnika, ale jeśli chcesz dokładniejszych informacji, zapoznaj się z linkiem.

Wycinanie cytatów w ciągach wyszukiwania wiersza poleceń
cudzysłowy w ciągach wyszukiwania wiersza poleceń muszą być unikane z odwrotnym ukośnikiem, jak \". Dotyczy to zarówno ciągów wyszukiwania dosłownego, jak i regex. To informacje zostały potwierdzone na XP, Vista i Windows 7.

Uwaga: cytat może również wymagać ucieczki dla CMD.Parser EXE, ale to nie ma nic wspólnego z FINDSTR. Na przykład, aby wyszukać pojedynczy cytat możesz użyć:

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

Unikanie ukośnika w wierszu poleceń
odwrotny ukośnik w literalnym ciągu wyszukiwania może być normalnie reprezentowany jako \ lub jako \\. Są one zazwyczaj równoważne. (mogą być niezwykłe przypadki w Vista, gdzie ukośnik musi być zawsze unikany, ale nie dłużej mieć maszynę Vista do przetestowania) .

Ale są pewne szczególne przypadki:

Podczas wyszukiwania kolejnych ukośniki, wszystkie oprócz ostatniego muszą być uciekł. Ostatni ukośnik może być opcjonalnie unikany.

\\ może być kodowane jako \\\ lub \\\\

\\\ może być kodowane jako \\\\\ lub \\\\\\

Szukanie jednego lub więcej ukośników przed cytatem jest dziwaczne. Logika sugerowałoby, że cytat musi być unikalny, a każdy z wiodących ukośniki powinny być unikane, ale to nie działa! Zamiast, każdy z wiodących ukośniki muszą być podwójne, a cytat jest normalnie:

\" musi być zakodowany jako \\\\\"

\\" musi być zakodowany jako \\\\\\\\\"

jak wspomniano wcześniej, jeden lub więcej cudzysłowów unikalnych może również wymagać wyrażenia escape z ^ dla parsera CMD

Informacje w tej sekcji zostały potwierdzone na XP i Windows 7.

Unikanie ukośnika wstecznego w wyszukiwaniu regex wiersza poleceń stringi

Vista only: Backslash w regex musi być albo podwójnym znakiem ucieczki, jak \\\\, albo pojedynczym znakiem ucieczki w zestawie klas znaków, jak [\\]

XP i Windows 7: odwrotny ukośnik w regex zawsze może być reprezentowany jako [\\]. Zwykle może być reprezentowana jako \\. Ale to nigdy działa, jeśli ukośnik poprzedza unikalny cytat.

Jeden lub więcej ukośników przed ucieczką cytat musi być dwa razy uciekł, albo zakodowany jako [\\]

\" może być kodowane jako \\\\\" lub [\\]\"

\\" mogą być kodowane jako \\\\\\\\\" lub [\\][\\]\" lub \\[\\]\"

Unikanie cudzysłowów i odwróconego ukośnika w /G: pliku literalnych ciągów wyszukiwania
Osobne cudzysłowy i odwrotne ukośniki w pliku z literalnym ciągiem znaków określonym przez /G: file nie muszą być oddzielone, ale mogą być.

" i \" są równoważne.

\ i \\ są równoważne.

Jeśli intencją jest znalezienie \\, to przynajmniej przedni ukośnik musi być unikalny. Zarówno \\\, jak i \\\\ działają.

Jeśli intencją jest znalezienie \", to przynajmniej przedni ukośnik musi być unikalny. Zarówno \\", jak i \\\" działają.

Unikanie cudzysłowów i ukośników wstecznych wewnątrz / G: ciągów wyszukiwania regex pliku
Jest to jedyny przypadek, w którym sekwencje specjalne działają zgodnie z oczekiwaniami na podstawie dokumentacji. Quote nie jest metacharakterem regex, więc nie musi być unikany (ale może być). Backslash jest metacharakterem regex, więc musi być unikany.

Limity znaków dla parametrów wiersza poleceń-Rozszerzona transformacja ASCII
Znak null (0x00) nie może pojawić się w żadnym łańcuchu w wierszu poleceń. W łańcuchu może pojawić się dowolny inny znak jednobajtowy (0x01 - 0xff). Jednak FINDSTR konwertuje wiele rozszerzonych znaków ASCII, które znajduje w parametry wiersza poleceń na inne znaki. Ma to duży wpływ na dwa sposoby: [145]}

1) wiele rozszerzonych znaków ASCII nie będzie pasować do siebie, jeśli zostaną użyte jako ciąg wyszukiwania w wierszu poleceń. To ograniczenie jest takie samo dla wyszukiwania dosłownego i regex. Jeśli szukany ciąg znaków musi zawierać rozszerzone ASCII, należy użyć opcji /G:FILE.

2) FINDSTR może nie znaleźć pliku, jeśli nazwa zawiera rozszerzone znaki ASCII, a nazwa pliku jest określona na wiersz poleceń. Jeśli przeszukiwany plik zawiera rozszerzone ASCII w nazwie, należy użyć opcji /F:FILE.

Oto pełna lista rozszerzonych przekształceń znaków ASCII, które FINDSTR wykonuje na ciągach wiersza poleceń. Każdy znak jest reprezentowany jako wartość kodu bajtów dziesiętnych. Pierwszy kod reprezentuje znak podany w wierszu poleceń, a drugi kod reprezentuje znak, w który jest przekształcany. Uwaga - lista ta została opracowana na U. S machine. Nie wiem, jaki wpływ na tę listę mogą mieć inne języki.

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

Każdy znak > 0 nie znajdujący się na powyższej liście jest traktowany jako sam w sobie, w tym <CR> i LF>. Najprostszym sposobem na dodanie znaków nieparzystych, takich jak <CR> i <LF>, jest umieszczenie ich w zmiennej środowiskowej i użycie opóźnionego rozszerzenia w argumencie wiersza poleceń.

Limity znaków dla ciągów znalezionych w plikach określonych przez opcje /G:FILE i / F: FILE
Nul (0x00) znak może pojawić się w pliku, ale działa jak Terminator ciągu C. Znaki po znaku nul są traktowane jako inny ciąg znaków tak, jakby znajdowały się w innej linii.

Znaki <CR> i <LF> są traktowane jako terminatory linii kończące łańcuch i nie są w nim zawarte.

Wszystkie inne znaki jednobajtowe są zawarte idealnie w ciągu znaków.

Wyszukiwanie Unicode pliki
FINDSTR nie może poprawnie przeszukiwać większości Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), ponieważ nie może wyszukiwać bajtów nul, a Unicode zazwyczaj zawiera wiele bajtów nul.

jednak polecenie TYPE konwertuje UTF-16LE z BOM na pojedynczy bajtowy zestaw znaków, więc polecenie takie jak poniżej będzie działać z UTF-16LE z BOM.

type unicode.txt|findstr "search"

należy pamiętać, że punkty kodu Unicode, które nie są obsługiwane przez aktywną stronę kodu, będą być przekonwertowane na znaki ?.

wyszukiwanie w UTF-8 jest możliwe pod warunkiem, że szukany ciąg zawiera tylko ASCII. Jednak wyjście konsoli dla wielobajtowych znaków UTF-8 nie będzie poprawne. Ale jeśli przekierujesz wyjście do pliku, wtedy wynik będzie poprawnie zakodowany UTF-8. Zauważ, że jeśli plik UTF-8 zawiera BOM, to BOM będzie uważany za część pierwszej linii, co może wyłączyć wyszukiwanie pasujące do początku Kolejka

możliwe jest przeszukiwanie wielobajtowych znaków UTF - 8, Jeśli umieścisz szukany ciąg w zakodowanym pliku wyszukiwania UTF-8 (bez BOM) i użyjesz opcji /G.

Koniec Linii
FINDSTR łamie linie natychmiast po każdym . Obecność lub brak nie ma wpływu na przerwy w linii.

Wyszukiwanie w poprzek linii
Zgodnie z oczekiwaniami, metacharakter regex . nie będzie pasował do lub . Ale możliwe jest przeszukiwanie po podziale linii za pomocą ciągu wyszukiwania wiersza poleceń. Zarówno znaki , jak i muszą być dopasowane jawnie. W przypadku znalezienia dopasowania wielowierszowego drukowana jest tylko pierwsza linia dopasowania. FINDSTR następnie podwaja się do drugiej linii w źródle i rozpoczyna wyszukiwanie od nowa-coś w rodzaju funkcji typu "patrz w przyszłość".

Załącz tekst.TXT ma taką zawartość (może to być styl Unix lub Windows)

A
A
A
B
A
A

Wtedy to skrypt

@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

Daje te wyniki

1:A
2:A
5:A

Przeszukiwanie podziałów linii za pomocą opcji / G: FILE jest nieprecyzyjne, ponieważ jedynym sposobem dopasowania lub jest wyrażenie zakresu klasy znaków regex, które Zastępuje znaki EOL.

[<TAB>-<0x0B>] pasuje do , ale pasuje również do i
[<0x0C>-!] pasuje , ale pasuje również i !

uwaga-powyższe są symboliczne reprezentacje strumienia bajtów regex, ponieważ nie mogę graficznie reprezentować znaków.

odpowiedź była kontynuowana w części 2 poniżej...