Der Windows-Befehl FINDSTR ist schrecklich dokumentiert. Es gibt eine sehr grundlegende Befehlszeilenhilfe, die über FINDSTR /?
oder verfügbar ist HELP FINDSTR
, die jedoch absolut unzureichend ist. Unter https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr .
Es gibt viele FINDSTR-Funktionen und -Einschränkungen, auf die in der Dokumentation nicht einmal hingewiesen wird. Sie könnten auch nicht ohne Vorkenntnisse und / oder sorgfältiges Experimentieren erwartet werden.
Die Frage ist also: Was sind die undokumentierten FINDSTR-Funktionen und -Einschränkungen?
Der Zweck dieser Frage besteht darin, ein One-Stop-Repository der vielen undokumentierten Funktionen bereitzustellen, damit:
A) Entwickler können die vorhandenen Funktionen voll ausnutzen.
B) Entwickler verschwenden keine Zeit damit, sich zu fragen, warum etwas nicht funktioniert, wenn es so scheint, wie es sollte.
Bitte stellen Sie sicher, dass Sie die vorhandene Dokumentation kennen, bevor Sie antworten. Wenn die Informationen von der HILFE abgedeckt werden, gehören sie nicht hierher.
Dies ist auch kein Ort, um interessante Anwendungen von FINDSTR zu zeigen. Wenn eine logische Person das Verhalten einer bestimmten Verwendung von FINDSTR basierend auf der Dokumentation vorhersehen könnte, dann gehört es nicht hierher.
In diesem Sinne gehört eine logische Person, die das Verhalten einer bestimmten Verwendung basierend auf Informationen, die in vorhandenen Antworten enthalten sind, vorhersehen könnte, nicht hierher.
quelle
grep
die sich sehr gut verstanden und dokumentiert :-) Siehe stackoverflow.com/questions/2635740/... zum Beispiel.Antworten:
Vorwort
Ein Großteil der Informationen in dieser Antwort wurde anhand von Experimenten gesammelt, die auf einem Vista-Computer ausgeführt wurden. Sofern nicht ausdrücklich anders angegeben, habe ich nicht bestätigt, ob die Informationen für andere Windows-Versionen gelten.
FINDSTR-Ausgabe
In der Dokumentation wird die Ausgabe von FINDSTR nie erläutert. Es spielt auf die Tatsache an, dass übereinstimmende Linien gedruckt werden, aber nichts weiter.
Das Format der übereinstimmenden Zeilenausgabe lautet wie folgt:
Dateiname: lineNumber: lineOffset: text
wo
Dateiname: = Der Name der Datei, die die übereinstimmende Zeile enthält. Der Dateiname wird nicht gedruckt, wenn die Anforderung explizit für eine einzelne Datei war oder wenn über Pipeline-Eingaben oder umgeleitete Eingaben gesucht wurde. Beim Drucken enthält der Dateiname immer alle bereitgestellten Pfadinformationen. Zusätzliche Pfadinformationen werden hinzugefügt, wenn die
/S
Option verwendet wird. Der gedruckte Pfad ist immer relativ zum angegebenen Pfad oder relativ zum aktuellen Verzeichnis, wenn keiner angegeben ist.Hinweis - Das Dateinamenpräfix kann beim Durchsuchen mehrerer Dateien mithilfe der nicht standardmäßigen (und schlecht dokumentierten) Platzhalter
<
und vermieden werden>
. Die genauen Regeln für die Funktionsweise dieser Platzhalter finden Sie hier . Schließlich können Sie sich dieses Beispiel ansehen, wie die nicht standardmäßigen Platzhalter mit FINDSTR funktionieren .lineNumber: = Die Zeilennummer der übereinstimmenden Zeile, die als Dezimalwert dargestellt wird, wobei 1 die erste Zeile der Eingabe darstellt. Wird nur gedruckt, wenn die
/N
Option angegeben ist.lineOffset: = Der Dezimalbyte-Offset des Beginns der übereinstimmenden Zeile, wobei 0 das 1. Zeichen der 1. Zeile darstellt. Wird nur gedruckt, wenn die
/O
Option angegeben ist. Dies ist nicht der Versatz der Übereinstimmung innerhalb der Linie. Dies ist die Anzahl der Bytes vom Anfang der Datei bis zum Anfang der Zeile.text = Die binäre Darstellung der übereinstimmenden Zeile, einschließlich aller <CR> und / oder <LF>. In der Binärausgabe wird nichts ausgelassen, sodass in diesem Beispiel, das mit allen Zeilen übereinstimmt, eine exakte Binärkopie der Originaldatei erstellt wird.
Die Option / A legt die Farbe der Ausgabe von fileName:, lineNumber: und lineOffset: fest. Der Text der übereinstimmenden Zeile wird immer mit der aktuellen Konsolenfarbe ausgegeben. Die Option / A wird nur wirksam, wenn die Ausgabe direkt auf der Konsole angezeigt wird. Die Option / A hat keine Auswirkung, wenn die Ausgabe in eine Datei umgeleitet oder weitergeleitet wird. Siehe die 2018.08.18 bearbeiten in Aacini Antwort für eine Beschreibung des Buggys Verhalten , wenn der Ausgang zu CON umgeleitet wird.
Die meisten Steuerzeichen und viele erweiterte ASCII-Zeichen werden unter XP als Punkte
angezeigt. FINDSTR unter XP zeigt die meisten nicht druckbaren Steuerzeichen aus übereinstimmenden Zeilen als Punkte (Punkte) auf dem Bildschirm an. Die folgenden Steuerzeichen sind Ausnahmen. Sie werden als sie selbst angezeigt: Registerkarte 0x09, LineFeed 0x0A, Registerkarte Vertikal 0x0B, Formularvorschub 0x0C, Wagenrücklauf 0x0D.
XP FINDSTR konvertiert auch eine Reihe erweiterter ASCII-Zeichen in Punkte. Die erweiterten ASCII-Zeichen, die unter XP als Punkte angezeigt werden, entsprechen denen, die bei der Eingabe in der Befehlszeile transformiert werden. Weitere Informationen finden Sie im Abschnitt "Zeichenbeschränkungen für Befehlszeilenparameter - Erweiterte ASCII-Transformation" weiter unten in diesem Beitrag
Steuerzeichen und erweitertes ASCII werden unter XP nicht in Punkte konvertiert, wenn die Ausgabe weitergeleitet, in eine Datei oder in eine FOR IN () -Klausel umgeleitet wird.
Vista und Windows 7 zeigen immer alle Zeichen als sich selbst an, niemals als Punkte.
Rückkehrcodes (ERRORLEVEL)
/A:xx
Option angegeben/L
und/R
beide angegeben/A:
,/F:
,/C:
,/D:
, oder/G:
/F:file
oder/G:file
nicht gefundenSie unter Regex-Zeichenklassenbegrenzung und BUG in Teil 2 der Antwort
Zu durchsuchende Datenquelle (Aktualisiert basierend auf Tests mit Windows 7)
Findstr kann Daten nur aus einer der folgenden Quellen suchen:
Dateinamen, die als Argumente angegeben werden und / oder die
/F:file
Option verwenden.stdin über Umleitung
findstr "searchString" <file
Datenstrom aus einer Pipe
type file | findstr "searchString"
Argumente / Optionen haben Vorrang vor der Umleitung, die Vorrang vor weitergeleiteten Daten hat.
Dateinamenargumente und
/F:file
können kombiniert werden. Es können mehrere Dateinamenargumente verwendet werden. Wenn mehrere/F:file
Optionen angegeben sind, wird nur die letzte verwendet. Platzhalter sind in Dateinamenargumenten zulässig, jedoch nicht in der Datei, auf die von verwiesen wird/F:file
.Quelle der Suchzeichenfolgen (Aktualisiert basierend auf Tests mit Windows 7)
Die Optionen
/G:file
und/C:string
können kombiniert werden. Es/C:string
können mehrere Optionen angegeben werden. Wenn mehrere/G:file
Optionen angegeben sind, wird nur die letzte verwendet. Wenn entweder/G:file
oder/C:string
verwendet wird, wird angenommen, dass alle Nichtoptionsargumente zu durchsuchende Dateien sind. Wenn weder/G:file
noch/C:string
verwendet wird, wird das erste Argument ohne Option als durch Leerzeichen getrennte Liste von Suchbegriffen behandelt.Dateinamen dürfen bei Verwendung der
/F:FILE
Option nicht in der Datei angegeben werden .Dateinamen können Leerzeichen und andere Sonderzeichen enthalten. Die meisten Befehle erfordern, dass solche Dateinamen in Anführungszeichen gesetzt werden. Die
/F:files.txt
Option FINDSTR erfordert jedoch, dass Dateinamen in files.txt NICHT in Anführungszeichen gesetzt werden dürfen. Die Datei wird nicht gefunden, wenn der Name in Anführungszeichen steht.BUG - Kurze 8.3-Dateinamen können die Optionen
/D
und brechen./S
Wie bei allen Windows-Befehlen versucht FINDSTR, bei der Suche nach zu durchsuchenden Dateien sowohl den langen als auch den kurzen 8.3-Namen abzugleichen. Angenommen, der aktuelle Ordner enthält die folgenden nicht leeren Dateien:
Der folgende Befehl findet erfolgreich alle 3 Dateien:
b.txt2
stimmt überein, weil der entsprechende KurznameB9F64~1.TXT
übereinstimmt. Dies stimmt mit dem Verhalten aller anderen Windows-Befehle überein.Ein Fehler mit den Optionen
/D
und führt jedoch dazu/S
, dass die folgenden Befehle nur gefunden werdenb1.txt
Der Fehler verhindert,
b.txt2
dass alle Dateinamen gefunden werden, nach denenb.txt2
im selben Verzeichnis sortiert wird . Zusätzliche Dateien, die zuvor sortiert wurdena.txt
, werden gefunden. Zusätzliche Dateien, die später sortiert werdend.txt
, werden übersehen, sobald der Fehler ausgelöst wurde.Jedes durchsuchte Verzeichnis wird unabhängig behandelt. Beispielsweise
/S
würde die Option erfolgreich mit der Suche in einem untergeordneten Ordner beginnen, nachdem keine Dateien im übergeordneten Ordner gefunden wurden. Sobald der Fehler jedoch dazu führt, dass ein kurzer Dateiname im untergeordneten Ordner übersehen wird, werden auch alle nachfolgenden Dateien in diesem untergeordneten Ordner übersehen .Die Befehle funktionieren fehlerfrei, wenn auf einem Computer, auf dem die NTFS 8.3-Namensgenerierung deaktiviert ist, dieselben Dateinamen erstellt werden. Natürlich
b.txt2
würde nicht gefunden werden, aberc.txt
würde richtig gefunden werden.Nicht alle Kurznamen lösen den Fehler aus. Alle Fälle von fehlerhaftem Verhalten, die ich gesehen habe, betreffen eine Erweiterung, die länger als 3 Zeichen ist, mit einem kurzen 8.3-Namen, der genauso beginnt wie ein normaler Name, für den kein 8.3-Name erforderlich ist.
Der Fehler wurde unter XP, Vista und Windows 7 bestätigt.
Nicht druckbare Zeichen und die
/P
OptionMit dieser
/P
Option überspringt FINDSTR alle Dateien, die einen der folgenden Dezimalbyte-Codes enthalten:0-7, 14-25, 27-31.
Anders ausgedrückt, die
/P
Option überspringt nur Dateien, die nicht druckbare Steuerzeichen enthalten. Steuerzeichen sind Codes kleiner oder gleich 31 (0x1F). FINDSTR behandelt die folgenden Steuerzeichen als druckbar:Alle anderen Steuerzeichen werden als nicht druckbar behandelt. Wenn sie vorhanden sind, kann
/P
die Datei übersprungen werden.Weitergeleitete und umgeleitete Eingabe wurde möglicherweise
<CR><LF>
angehängt.Wenn die Eingabe weitergeleitet wird und das letzte Zeichen des Streams nicht angehängt ist
<LF>
, wird FINDSTR automatisch<CR><LF>
an die Eingabe angehängt . Dies wurde unter XP, Vista und Windows 7 bestätigt. (Früher dachte ich, dass die Windows-Pipe für die Änderung der Eingabe verantwortlich ist, aber seitdem habe ich festgestellt, dass FINDSTR die Änderung tatsächlich vornimmt.)Gleiches gilt für umgeleitete Eingaben unter Vista. Wenn das letzte Zeichen einer Datei, die als umgeleitete Eingabe verwendet wird, nicht ist
<LF>
, wird FINDSTR automatisch<CR><LF>
an die Eingabe angehängt . XP und Windows 7 ändern jedoch keine umgeleiteten Eingaben.FINDSTR hängt unter XP und Windows 7, wenn die umgeleitete Eingabe nicht mit endet.
<LF>
Dies ist eine unangenehme "Funktion" unter XP und Windows 7. Wenn das letzte Zeichen einer Datei, die als umgeleitete Eingabe verwendet wird, nicht mit
<LF>
endet, bleibt FINDSTR auf unbestimmte Zeit hängen erreicht das Ende der umgeleiteten Datei.Die letzte Zeile der weitergeleiteten Daten wird möglicherweise ignoriert, wenn sie aus einem einzelnen Zeichen besteht.
Wenn die Eingabe eingespeist wird und die letzte Zeile aus einem einzelnen Zeichen besteht, auf das nicht folgt
<LF>
, ignoriert FINDSTR die letzte Zeile vollständig.Beispiel - Der erste Befehl mit einem einzelnen Zeichen und nein
<LF>
stimmt nicht überein, aber der zweite Befehl mit 2 Zeichen funktioniert einwandfrei, ebenso wie der dritte Befehl, der ein Zeichen mit abschließendem Zeilenumbruch enthält.Berichtet von DosTips-Benutzer Sponge Belly bei neuem findstr-Fehler . Bestätigt unter XP, Windows 7 und Windows 8. Ich habe noch nichts von Vista gehört. (Ich muss Vista nicht mehr testen).
Optionssyntax
Optionen können entweder vorangestellt werden
/
oder-
Optionen können nach einem einzelnen/
oder verkettet werden-
. Die verkettete Optionsliste kann jedoch höchstens eine Option mit mehreren Zeichen wie AUS oder F: enthalten, und die Option mit mehreren Zeichen muss die letzte Option in der Liste sein.Im Folgenden finden Sie alle äquivalenten Möglichkeiten, um eine Regex-Suche ohne Berücksichtigung der Groß- und Kleinschreibung für eine Zeile auszudrücken, die sowohl "Hallo" als auch "Auf Wiedersehen" in beliebiger Reihenfolge enthält
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
Längenbeschränkungen für Suchzeichenfolgen
Unter Vista beträgt die maximal zulässige Länge für eine einzelne Suchzeichenfolge 511 Byte. Wenn eine
FINDSTR: Search string too long.
Suchzeichenfolge 511 überschreitet, ist das Ergebnis ein Fehler mit ERRORLEVEL 2.Bei einer Suche nach regulären Ausdrücken beträgt die maximale Länge der
FINDSTR: Out of memory
Suchzeichenfolge 254. Ein regulärer Ausdruck mit einer Länge zwischen 255 und 511 führt zu einem Fehler mit ERRORLEVEL 2. Eine Länge eines regulären Ausdrucks> 511 führt zu demFINDSTR: Search string too long.
Fehler.Unter Windows XP ist die Länge der Suchzeichenfolge anscheinend kürzer. Findstr-Fehler: "Suchzeichenfolge zu lang": Wie wird die Teilzeichenfolge in der "for" -Schleife extrahiert und abgeglichen? Das XP-Limit beträgt 127 Byte für Literal- und Regex-Suchen.
Zeilenlängenbeschränkungen
Dateien, die als Befehlszeilenargument oder über die Option / F: FILE angegeben wurden, haben keine bekannte Zeilenlängenbeschränkung. Die Suche wurde erfolgreich für eine 128-MB-Datei ausgeführt, die kein einziges <LF> enthielt.
Weitergeleitete Daten und umgeleitete Eingaben sind auf 8191 Byte pro Zeile begrenzt. Diese Grenze ist ein "Merkmal" von FINDSTR. Es ist nicht mit Rohren oder Umleitungen verbunden. FINDSTR, das umgeleitete stdin- oder Piped-Eingaben verwendet, stimmt niemals mit einer Zeile überein, die> = 8 KByte ist. Zeilen> = 8k erzeugen eine Fehlermeldung an stderr, aber ERRORLEVEL ist immer noch 0, wenn die Suchzeichenfolge in mindestens einer Zeile von mindestens einer Datei gefunden wird.
Standard-Suchtyp: Literal vs Regular Expression
/C:"string"
- Der Standard ist / L Literal. Das explizite Kombinieren der Option / L mit / C: "string" funktioniert zwar, ist aber redundant."string argument"
- Die Standardeinstellung hängt vom Inhalt der ersten Suchzeichenfolge ab. (Denken Sie daran, dass <Leerzeichen> zum Abgrenzen von Suchzeichenfolgen verwendet wird.) Wenn die erste Suchzeichenfolge ein gültiger regulärer Ausdruck ist, der mindestens ein nicht maskiertes Metazeichen enthält, werden alle Suchzeichenfolgen als reguläre Ausdrücke behandelt. Andernfalls werden alle Suchzeichenfolgen als Literale behandelt. Zum Beispiel"51.4 200"
wird als zwei reguläre Ausdrücke behandelt werden , da die erste Zeichenfolge einen nicht entgangen Punkt enthält, während"200 51.4"
als zwei Literale behandelt werden , da die erste Saite kein Meta-Zeichen enthält./G:file
- Die Standardeinstellung hängt vom Inhalt der ersten nicht leeren Zeile in der Datei ab. Wenn die erste Suchzeichenfolge ein gültiger regulärer Ausdruck ist, der mindestens ein nicht maskiertes Metazeichen enthält, werden alle Suchzeichenfolgen als reguläre Ausdrücke behandelt. Andernfalls werden alle Suchzeichenfolgen als Literale behandelt.Empfehlung - Geben Sie bei Verwendung von oder immer explizit die
/L
Literaloption oder die Option für/R
reguläre Ausdrücke an ."string argument"
/G:file
BUG - Die Angabe mehrerer Literal-Suchzeichenfolgen kann zu unzuverlässigen Ergebnissen führen
Das folgende einfache FINDSTR-Beispiel findet keine Übereinstimmung, obwohl dies der Fall sein sollte.
Dieser Fehler wurde unter Windows Server 2003, Windows XP, Vista und Windows 7 bestätigt.
Basierend auf Experimenten kann FINDSTR fehlschlagen, wenn alle folgenden Bedingungen erfüllt sind:
/I
Option).Bei jedem Fehler, den ich gesehen habe, ist es immer eine der kürzeren Suchzeichenfolgen, die fehlschlägt.
Weitere Informationen finden Sie unter Warum findet dieses FINDSTR-Beispiel mit mehreren Literal-Suchzeichenfolgen keine Übereinstimmung?
Escape-
Anführungszeichen und Backslash in / G: FILE-Literal-Suchzeichenfolgen Eigenständige Anführungszeichen und Backslashes in einer durch / G: -Datei angegebenen Literal-Suchzeichenfolge müssen nicht maskiert werden, können es aber sein.
"
und\"
sind gleichwertig.\
und\\
sind gleichwertig.Wenn die Absicht besteht, \\ zu finden, muss mindestens der führende Backslash maskiert werden. Beides
\\\
und\\\\
Arbeit.Wenn die Absicht besteht, "" zu finden, muss mindestens der führende Backslash maskiert werden. Beides
\\"
und\\\"
funktionieren.Escape-Anführungszeichen und Backslash in / G: FILE-Regex-Suchzeichenfolgen
Dies ist der einzige Fall, in dem die Escape-Sequenzen gemäß der Dokumentation wie erwartet funktionieren. Quote ist kein Regex-Metazeichen, daher muss es nicht maskiert werden (kann es aber sein). Backslash ist ein Regex-Metazeichen, daher muss es maskiert werden.
Zeichenbeschränkungen für Befehlszeilenparameter - Erweiterte ASCII-Umwandlung Das Nullzeichen (0x00) kann in keiner Zeichenfolge in der Befehlszeile angezeigt werden. Jedes andere Einzelbytezeichen kann in der Zeichenfolge erscheinen (0x01 - 0xFF). FINDSTR konvertiert jedoch viele erweiterte ASCII-Zeichen, die in Befehlszeilenparametern gefunden werden, in andere Zeichen. Dies hat zwei wesentliche Auswirkungen:
1) Viele erweiterte ASCII-Zeichen stimmen nicht überein, wenn sie als Suchzeichenfolge in der Befehlszeile verwendet werden. Diese Einschränkung gilt auch für Literal- und Regex-Suchen. Wenn eine Suchzeichenfolge erweitertes ASCII enthalten muss,
/G:FILE
sollte stattdessen die Option verwendet werden.2) FINDSTR kann möglicherweise keine Datei finden, wenn der Name erweiterte ASCII-Zeichen enthält und der Dateiname in der Befehlszeile angegeben ist. Wenn eine zu durchsuchende Datei erweitertes ASCII im Namen enthält,
/F:FILE
sollte stattdessen die Option verwendet werden.Hier finden Sie eine vollständige Liste der erweiterten ASCII-Zeichentransformationen, die FINDSTR für Befehlszeilenzeichenfolgen ausführt. Jedes Zeichen wird als Dezimalbytecodewert dargestellt. Der erste Code repräsentiert das Zeichen, wie es in der Befehlszeile angegeben ist, und der zweite Code repräsentiert das Zeichen, in das es transformiert wird. Hinweis - Diese Liste wurde auf einem US-Computer erstellt. Ich weiß nicht, welchen Einfluss andere Sprachen auf diese Liste haben könnten.
Jedes Zeichen> 0, das nicht in der obigen Liste enthalten ist, wird als sich selbst behandelt, einschließlich
<CR>
und <LF>
. Der einfachste Weg, ungerade Zeichen wie<CR>
und einzuschließen,<LF>
besteht darin, sie in eine Umgebungsvariable zu integrieren und eine verzögerte Erweiterung innerhalb des Befehlszeilenarguments zu verwenden.Zeichenbeschränkungen für Zeichenfolgen, die in Dateien gefunden werden, die durch die Optionen / G: FILE und / F: FILE angegeben sind.
Das Zeichen nul (0x00) kann in der Datei angezeigt werden, funktioniert jedoch wie der C-Zeichenfolgenabschluss. Alle Zeichen nach einem Nullzeichen werden als eine andere Zeichenfolge behandelt, als wären sie in einer anderen Zeile.
Die Zeichen
<CR>
und<LF>
werden als Zeilenabschlusszeichen behandelt, die eine Zeichenfolge beenden, und sind nicht in der Zeichenfolge enthalten.Alle anderen Einzelbytezeichen sind perfekt in einer Zeichenfolge enthalten.
Durchsuchen von Unicode-Dateien FINDSTR kann die meisten Unicode-Dateien
(UTF-16, UTF-16LE, UTF-16BE, UTF-32) nicht ordnungsgemäß durchsuchen, da es nicht nach Null-Bytes suchen kann und Unicode normalerweise viele Null-Bytes enthält.
Der Befehl TYPE konvertiert jedoch UTF-16LE mit Stückliste in einen Einzelbyte-Zeichensatz, sodass ein Befehl wie der folgende mit UTF-16LE mit Stückliste funktioniert.
Beachten Sie, dass Unicode-Codepunkte, die von Ihrer aktiven Codepage nicht unterstützt werden, in
?
Zeichen konvertiert werden .Es ist möglich, UTF-8 zu durchsuchen, solange Ihre Suchzeichenfolge nur ASCII enthält. Die Konsolenausgabe von Multi-Byte-UTF-8-Zeichen ist jedoch nicht korrekt. Wenn Sie die Ausgabe jedoch in eine Datei umleiten, wird das Ergebnis korrekt in UTF-8 codiert. Beachten Sie, dass wenn die UTF-8-Datei eine Stückliste enthält, die Stückliste als Teil der ersten Zeile betrachtet wird, wodurch eine Suche ausgelöst werden kann, die dem Zeilenanfang entspricht.
Es ist möglich, Multi-Byte-UTF-8-Zeichen zu durchsuchen, wenn Sie Ihre Suchzeichenfolge in eine UTF-8-codierte Suchdatei (ohne Stückliste) einfügen und die Option / G verwenden.
End Of Line
FINDSTR bricht Zeilen unmittelbar nach jedem <LF>. Das Vorhandensein oder Fehlen von <CR> hat keinen Einfluss auf Zeilenumbrüche.
Suchen über Zeilenumbrüche
Wie erwartet
.
stimmt das Regex-Metazeichen nicht mit <CR> oder <LF> überein. Es ist jedoch möglich, mithilfe einer Befehlszeilensuchzeichenfolge über einen Zeilenumbruch hinweg zu suchen. Sowohl die Zeichen <CR> als auch <LF> müssen explizit übereinstimmen. Wenn eine mehrzeilige Übereinstimmung gefunden wird, wird nur die erste Zeile der Übereinstimmung gedruckt. FINDSTR kehrt dann zur zweiten Zeile in der Quelle zurück und beginnt die Suche erneut - eine Art Feature vom Typ "Vorausschau".Angenommen, TEXT.TXT enthält diese Inhalte (könnte Unix- oder Windows-Stil sein).
Dann dieses Skript
gibt diese Ergebnisse
Das Durchsuchen von Zeilenumbrüchen mit der Option / G: FILE ist ungenau, da <CR> oder <LF> nur über einen Ausdrucksbereich für Regex-Zeichenklassen abgeglichen werden können, der die EOL-Zeichen enthält.
[<TAB>-<0x0B>]
stimmt mit <LF> überein, stimmt aber auch mit <TAB> und <0x0B> überein[<0x0C>-!]
stimmt mit <CR> überein, aber es stimmt auch mit <0x0C> und überein!Hinweis - Die obigen Angaben sind symbolische Darstellungen des Regex-Byte-Streams, da ich die Zeichen nicht grafisch darstellen kann.
Antwort weiter in Teil 2 unten ...
quelle
addpath.bat
von Q141344 und findstr, die den Win7 hängenden Problem in Zusammenhang stehen können oben erwähnt. Ich habe einen Chatroom erstellt, um dies für alle Interessierten aufzuspüren/S
und/D
Optionen dokumentiert , die sich aus kurzen 8.3-Dateinamen ergeben.<LF>
Antwort Fortsetzung von Teil 1 oben - Ich bin auf das Antwortlimit von 30.000 Zeichen gestoßen :-(
Unterstützung für eingeschränkte reguläre Ausdrücke (Regex) Die Unterstützung von FINDSTR für reguläre Ausdrücke ist äußerst begrenzt. Wenn es nicht in der HELP-Dokumentation enthalten ist, wird es nicht unterstützt.
Darüber hinaus werden die unterstützten Regex-Ausdrücke auf eine völlig unstandardisierte Weise implementiert, sodass die Ergebnisse anders ausfallen können, als dies von grep oder perl erwartet wird.
Die Regex-Linienpositionsanker ^ und $
^
stimmen mit dem Beginn des Eingabestreams sowie mit jeder Position unmittelbar nach einem <LF> überein. Da FINDSTR auch Zeilen nach <LF> unterbricht, stimmt ein einfacher regulärer Ausdruck von "^" immer mit allen Zeilen innerhalb einer Datei überein, auch mit einer Binärdatei.$
Entspricht jeder Position unmittelbar vor einem <CR>. Dies bedeutet, dass eine Regex-Suchzeichenfolge, die enthält$
, niemals mit Zeilen in einer Textdatei im Unix-Stil übereinstimmt und auch nicht mit der letzten Zeile einer Windows-Textdatei übereinstimmt, wenn die EOL-Markierung von <CR> <LF> fehlt.Hinweis - Wie bereits erwähnt, wurde möglicherweise eine
<CR><LF>
an PINDSTR weitergeleitete und umgeleitete Eingabe angehängt, die sich nicht in der Quelle befindet. Dies kann sich natürlich auf eine Regex-Suche auswirken, die verwendet wird$
.Jede Suchzeichenfolge mit Zeichen davor
^
oder danach$
findet immer keine Übereinstimmung.Positionsoptionen / B / E / X
Die Positionsoptionen funktionieren genauso wie
^
und$
, außer dass sie auch für wörtliche Suchzeichenfolgen funktionieren./ B funktioniert genauso wie
^
am Anfang einer Regex-Suchzeichenfolge./ E funktioniert genauso wie
$
am Ende einer Regex-Suchzeichenfolge./ X funktioniert genauso wie
^
am Anfang und$
am Ende einer Regex-Suchzeichenfolge.Die Regex-Wortgrenze
\<
muss der allererste Term im Regex sein. Die Regex stimmt mit nichts überein, wenn andere Zeichen davor stehen.\<
entspricht entweder dem Anfang der Eingabe, dem Anfang einer Zeile (die Position unmittelbar nach einem <LF>) oder der Position unmittelbar nach einem "Nicht-Wort" -Zeichen. Das nächste Zeichen muss kein "Wort" -Zeichen sein.\>
muss der allerletzte Begriff in der Regex sein. Die Regex stimmt mit nichts überein, wenn andere Zeichen darauf folgen.\>
entspricht entweder dem Ende der Eingabe, der Position unmittelbar vor einem <CR> oder der Position unmittelbar vor einem "Nicht-Wort" -Zeichen. Das vorhergehende Zeichen muss kein "Wort" -Zeichen sein.Hier ist eine vollständige Liste von "Nicht-Wort" -Zeichen, die als Dezimalbytecode dargestellt werden. Hinweis - Diese Liste wurde auf einem US-Computer erstellt. Ich weiß nicht, welchen Einfluss andere Sprachen auf diese Liste haben könnten.
Regex-Zeichenklassenbereiche [xy]
Zeichenklassenbereiche funktionieren nicht wie erwartet. Siehe diese Frage: Warum behandelt findstr den Fall (unter bestimmten Umständen) nicht richtig? , zusammen mit dieser Antwort: https://stackoverflow.com/a/8767815/1012053 .
Das Problem ist, dass FINDSTR die Zeichen nicht nach ihrem Bytecodewert sortiert (üblicherweise als ASCII-Code gedacht, aber ASCII wird nur von 0x00 - 0x7F definiert). Die meisten Regex-Implementierungen würden [AZ] als alle englischen Großbuchstaben in Großbuchstaben behandeln. FINDSTR verwendet jedoch eine Sortierfolge, die in etwa der Funktionsweise von SORT entspricht. [AZ] enthält also das vollständige englische Alphabet, sowohl in Groß- als auch in Kleinbuchstaben (mit Ausnahme von "a"), sowie nicht-englische Alpha-Zeichen mit diakritischen Zeichen.
Unten finden Sie eine vollständige Liste aller von FINDSTR unterstützten Zeichen, sortiert nach der von FINDSTR zum Festlegen von Regex-Zeichenklassenbereichen verwendeten Sortierfolge. Die Zeichen werden als ihr Dezimalbytecodewert dargestellt. Ich glaube, die Sortierfolge ist am sinnvollsten, wenn die Zeichen mit Codepage 437 angezeigt werden. Hinweis - Diese Liste wurde auf einem US-Computer erstellt. Ich weiß nicht, welchen Einfluss andere Sprachen auf diese Liste haben könnten.
Regex-Zeichenklassenbegriffsbegrenzung und BUG
FINDSTR ist nicht nur auf maximal 15 Zeichenklassenbegriffe innerhalb eines Regex beschränkt, sondern behandelt auch den Versuch, das Grenzwert zu überschreiten, nicht ordnungsgemäß. Die Verwendung von 16 oder mehr Zeichenklassenbegriffen führt zu einem interaktiven Windows-Popup mit der Meldung "Das Dienstprogramm zum Suchen von Zeichenfolgen (QGREP) ist auf ein Problem gestoßen und muss geschlossen werden. Wir entschuldigen uns für die Unannehmlichkeiten." Der Nachrichtentext variiert je nach Windows-Version geringfügig. Hier ist ein Beispiel für einen FINDSTR, der fehlschlägt:
Dieser Fehler wurde vom DosTips-Benutzer Judago hier gemeldet . Es wurde unter XP, Vista und Windows 7 bestätigt.
Regex-Suchen schlagen fehl (und können unbegrenzt hängen bleiben), wenn sie den Bytecode 0xFF (dezimal 255) enthalten.
Jede Regex-Suche, die den Bytecode 0xFF (dezimal 255) enthält, schlägt fehl. Es schlägt fehl, wenn der Bytecode 0xFF direkt enthalten ist oder implizit in einem Zeichenklassenbereich enthalten ist. Beachten Sie, dass in FINDSTR-Zeichenklassenbereichen keine Zeichen basierend auf dem Bytecodewert sortiert werden. Das Zeichen
<0xFF>
erscheint relativ früh in der Kollatierungssequenz zwischen den Zeichen<space>
und<tab>
. Jeder Zeichenklassenbereich, der beides enthält<space>
und<tab>
fehlschlägt.Das genaue Verhalten ändert sich je nach Windows-Version geringfügig. Windows 7 bleibt auf unbestimmte Zeit hängen, wenn 0xFF enthalten ist. XP hängt nicht, findet jedoch immer keine Übereinstimmung und gibt gelegentlich die folgende Fehlermeldung aus: "Der Prozess hat versucht, in eine nicht vorhandene Pipe zu schreiben."
Ich habe keinen Zugriff mehr auf einen Vista-Computer, daher konnte ich unter Vista nicht testen.
Regex-Fehler:
.
und[^anySet]
kann mit dem Dateiende übereinstimmenDas Regex
.
- Metazeichen sollte nur mit einem anderen Zeichen als<CR>
oder übereinstimmen<LF>
. Es gibt einen Fehler, der es ermöglicht, mit dem Dateiende übereinzustimmen, wenn die letzte Zeile in der Datei nicht durch beendet wird<CR>
oder<LF>
. Das.
passt jedoch nicht zu einer leeren Datei.Zum Beispiel eine Datei mit dem Namen "test.txt", die eine einzelne Zeile von enthält
x
, ohne<CR>
oder zu beenden<LF>
, mit der folgenden :Dieser Fehler wurde unter XP und Win7 bestätigt.
Gleiches scheint für negative Zeichensätze zu gelten. So etwas passt zum
[^abc]
Dateiende. Positive Zeichensätze[abc]
scheinen gut zu funktionieren. Ich habe dies nur auf Win7 getestet.quelle
type
in zu leitenfindstr
.findstr
mehrere Suchzeichenfolgen unterstützt werden/c:
. Ich weiß, dass Ihre Antworten dies zeigen. Aber es ist etwas, das nicht dokumentiert ist; und ich war ziemlich überrascht, von der Funktion zu erfahren, nachdem ichfindstr
sie einige Jahre lang ohne sie verwendet hatte.LF
Ihnen dokumentierten Problems aus. Ich habe festgestellt, dass meine Testdatei nicht beendet wurde,LF
weil ich siecopy
im Anhänge-Modus erstellt habe. Ich habe eine Befehlszeilensitzung eingefügt , um das Problem in einer Antwort zu demonstrieren ( stackoverflow.com/a/22943056/224704 ). Beachten Sie, dass die Eingabe nicht umgeleitet wird und die Suche dennoch hängt. Der exakt gleiche Suchbefehl hängt nicht mit kleineren Dateien zusammen, die ebenfalls nicht endenLF
.findstr /R /C:"^[0-9][0-9]* [0-3][0-9][0-9]-[0-9][0-9]:[0-5][0-9]:[0-5][0-9]\.[0-9][0-9]* [0-9]*\.[0-9]*"
(15 Zeichenklassen) -ErrorLevel = -1073740791 (0xC0000409)
, Fehlerdialogfenster :Find String (QGREP) Utility has stopped working
; Nach dem Entfernen einer Klasse oder zwei Meta-Zeichen (*\.
) funktioniert es ...findstr
hängt manchmal unerwartet beim Durchsuchen großer Dateien.Ich habe die genauen Bedingungen oder Grenzgrößen nicht bestätigt. Ich vermute, dass jede Datei mit mehr als 2 GB gefährdet ist.
Ich habe gemischte Erfahrungen damit gemacht, es ist also mehr als nur Dateigröße. Dies scheint eine Variation von FINDSTR zu sein, die unter XP und Windows 7 hängt, wenn die umgeleitete Eingabe nicht mit LF endet. Wie gezeigt, tritt dieses spezielle Problem jedoch auf, wenn die Eingabe nicht erfolgt umgeleitet wird.
Die folgende Befehlszeilensitzung (Windows 7) zeigt, wie
findstr
beim Durchsuchen einer 3-GB-Datei hängen bleiben kann.Beachten Sie, dass ich in einem Hex-Editor überprüft habe, dass alle Zeilen mit abgeschlossen sind
CRLF
. Die einzige Anomalie ist , dass die Datei mit beendet wird0x1A
aufgrund der Art und Weisecopy
funktioniert . Beachten Sie jedoch, dass diese Anomalie bei "kleinen" Dateien kein Problem verursacht .Mit zusätzlichen Tests habe ich Folgendes bestätigt:
copy
mit der/b
Option für Binärdateien verhindert das Hinzufügen des0x1A
Zeichens undfindstr
hängt nicht an der 3-GB-Datei.findstr
hängen.0x1A
Charakter verursacht keine Probleme in einer "kleinen" Datei. (Ähnliches gilt für andere abschließende Zeichen.)CRLF
nach wird0x1A
das Problem behoben. (LF
allein würde wahrscheinlich ausreichen.)type
um die Datei infindstr
Werke zu leiten, ohne zu hängen. (Dies kann auf einen Nebeneffekt von entweder zurückzuführen seintype
oder|
ein zusätzliches Zeilenende einfügen.)<
auchfindstr
zum Hängenbleiben. Dies wird aber erwartet; wie in dbenhams post erklärt : "umgeleitete eingaben müssen mit endenLF
" .quelle
<LF>
. Eine zwei Byte kleinere Datei hing nicht. Sehr böse!Wenn mehrere Befehle in Klammern stehen und Dateien in den gesamten Block umgeleitet werden:
... dann bleiben die Dateien geöffnet, solange die Befehle im Block aktiv sind, sodass die Befehle den Dateizeiger der umgeleiteten Dateien verschieben können. Sowohl der Befehl MORE als auch der Befehl FIND verschieben den Stdin-Dateizeiger vor der Verarbeitung an den Anfang der Datei, sodass dieselbe Datei innerhalb des Blocks möglicherweise mehrmals verarbeitet wird. Zum Beispiel dieser Code:
... das gleiche Ergebnis erzielen wie dieses:
Dieser Code:
... das gleiche Ergebnis erzielen wie dieses:
FINDSTR ist anders; es ist nicht die Stdin Dateizeiger von seiner aktuellen Position bewegen. Mit diesem Code wird beispielsweise eine neue Zeile nach einer Suchzeile eingefügt:
Wir können diese Funktion mit Hilfe eines Hilfsprogramms nutzen, mit dem wir den Dateizeiger einer umgeleiteten Datei verschieben können, wie in diesem Beispiel gezeigt .
Dieses Verhalten wurde zuerst von jeb in diesem Beitrag gemeldet .
EDIT 2018-08-18 : Neuer FINDSTR-Fehler gemeldet
Der Befehl FINDSTR weist einen seltsamen Fehler auf, der auftritt, wenn dieser Befehl zum Anzeigen von Zeichen in Farbe verwendet wird UND die Ausgabe eines solchen Befehls an das CON-Gerät umgeleitet wird. Ausführliche Informationen zur Verwendung des Befehls FINDSTR zum Anzeigen von Text in Farbe finden Sie in diesem Thema .
Wenn die Ausgabe dieser Form des FINDSTR-Befehls an CON umgeleitet wird, passiert etwas Seltsames, nachdem der Text in der gewünschten Farbe ausgegeben wurde: Der gesamte Text nach der Ausgabe als "unsichtbare" Zeichen, obwohl eine genauere Beschreibung lautet, dass der Text ist Ausgabe als schwarzer Text über schwarzem Hintergrund. Der Originaltext wird angezeigt, wenn Sie mit dem Befehl COLOR die Vordergrund- und Hintergrundfarben des gesamten Bildschirms zurücksetzen. Wenn der Text jedoch "unsichtbar" ist, können wir einen SET / P-Befehl ausführen, sodass nicht alle eingegebenen Zeichen auf dem Bildschirm angezeigt werden. Dieses Verhalten kann zur Eingabe von Passwörtern verwendet werden.
quelle
Ich möchte einen Fehler in Bezug auf den Abschnitt Datenquelle melden , nach der in der ersten Antwort gesucht werden soll , wenn en dash (-) oder em dash (-) im Dateinamen verwendet werden.
Wenn Sie die erste Option verwenden möchten - Dateinamen, die als Argumente angegeben werden , wird die Datei nicht gefunden. Sobald Sie entweder Option 2 - Standard über Umleitung oder 3 - Datenstrom aus einer Pipe verwenden , findet findstr die Datei.
Zum Beispiel dieses einfache Batch-Skript:
wird drucken:
Dateiname mit en dash:
Als Argument
FINDSTR: Dateiname kann nicht mit - dash.txt geöffnet werden
Als Standard über Umleitung
bin ich die Datei mit einem Bindestrich.
Als Datenstrom aus einer Pipe
bin ich die Datei mit einem Bindestrich.
Dateiname mit Bindestrich:
Als Argument
FINDSTR: Dateiname kann nicht mit - dash.txt geöffnet werden
Als Standard über Umleitung
bin ich die Datei mit einem em-Strich.
Als Datenstrom aus einer Pipe
bin ich die Datei mit einem em-Strich.
Ich hoffe es hilft.
M.
quelle
Das
findstr
Befehl setzt denErrorLevel
(oder Exit-Code) auf einen der folgenden Werte, da keine ungültigen oder inkompatiblen Schalter vorhanden sind und keine Suchzeichenfolge die geltende Längenbeschränkung überschreitet:0
wenn in allen angegebenen Dateien mindestens eine einzige Übereinstimmung in einer Zeile gefunden wird;1
Andernfalls;Eine Zeile enthält eine Übereinstimmung, wenn:
/V
Option angegeben und der Suchausdruck kommt mindestens einmal vor./V
Option ist angegeben und der Suchausdruck wird nicht angezeigt.Dies bedeutet, dass die
/V
Option auch die zurückgegebenen ändertErrorLevel
, diese jedoch nicht einfach zurücksetzt!Wenn Sie beispielsweise eine Datei
test.txt
mit zwei Zeilen haben, von denen eine die Zeichenfolge enthälttext
, die andere jedoch nicht, beidefindstr "text" "test.txt"
undfindstr /V "text" "test.txt"
eineErrorLevel
von zurückgeben0
.Grundsätzlich kann man sagen: Wenn
findstr
mindestens eine Zeile zurückgegeben wird,ErrorLevel
wird auf gesetzt0
, sonst auf1
.Beachten Sie, dass die
/M
Option denErrorLevel
Wert nicht beeinflusst , sondern nur die Ausgabe ändert.(Nur der Vollständigkeit halber: Der
find
Befehl verhält sich in Bezug auf die/V
Option genauso undErrorLevel
die/C
Option hat keinen EinflussErrorLevel
.)quelle
FINDSTR hat einen Farbfehler, den ich unter /superuser/1535810/is-there-a-better-way-to-mitigate-this-obscure-color-bug-when-piping-to beschrieben und behoben habe -findstr / 1538802? noredirect = 1 # comment2339443_1538802
Um diesen Thread zusammenzufassen: Der Fehler besteht darin, dass Inline-ANSI-Escape-Farbcodes in später ausgeführten Befehlen nicht mehr funktionieren, wenn die Eingabe innerhalb eines in Klammern gesetzten Codeblocks an FINDSTR weitergeleitet wird. Ein Beispiel für Inline-Farbcodes ist:
echo %magenta%Alert: Something bad happened%yellow%
(wobei Magenta und Gelb sind, die zuvor in der .bat-Datei als entsprechende ANSI-Escape-Farbcodes definiert wurden).Meine anfängliche Lösung bestand darin, nach dem FINDSTR eine Nicht-Unterroutine aufzurufen. Irgendwie "setzt" der Anruf oder die Rückgabe alles zurück, was zurückgesetzt werden muss.
Später entdeckte ich eine andere Lösung, die vermutlich effizienter ist: Platzieren Sie die FINDSTR-Phrase in Klammern, wie im folgenden Beispiel:
echo success | ( FINDSTR /R success )
Das Platzieren der FINDSTR-Phrase in einem verschachtelten Codeblock scheint den Farbcode-Fehler von FINDSTR zu isolieren, sodass er keinen Einfluss darauf hat, was sich außerhalb der verschachtelten befindet Block. Vielleicht löst diese Technik auch einige andere unerwünschte FINDSTR-Nebenwirkungen .quelle
/ D Tipp für mehrere Verzeichnisse: Stellen Sie Ihre Verzeichnisliste vor die Suchzeichenfolge. Diese alle funktionieren:
Wie erwartet ist der Pfad relativ zum Speicherort, wenn Sie die Verzeichnisse nicht mit starten
\
. Das Umgeben des Pfads mit"
ist optional, wenn die Verzeichnisnamen keine Leerzeichen enthalten. Das Ende\
ist optional. Die Ausgabe des Standorts enthält den von Ihnen angegebenen Pfad. Es funktioniert mit oder ohne Umgeben der Verzeichnisliste mit"
.quelle
/D:dirlist Search a semicolon-delimited list of directories
und er steht vor der Suchzeichenfolge, so dass ich nicht verstehe, was genau "Sie" über den / D-Schalter gefunden haben (und was sind die "Befehle, die" NICHT arbeiten ") ...findstr
Listen / D. Ja, ich habe kein Argument dafür, dass das Feature dokumentiert wird. Es ist nur nicht dokumentiert, dass die Reihenfolge der Attribute von Bedeutung ist. Ich mache sehr wenig Kommandozeilenarbeit. Als ich also einen Befehl gepflastert habe und nicht wusste, dass die Reihenfolge einen Unterschied macht, habe ich nur die Attribute hinzugefügt, als ich zu ihnen kam (und alphabetisch steht C vor D). Ich war sehr frustriert und habe meine "gefundenen" Erfahrungen für alle anderen geteilt, die nicht viel mit der Kommandozeile arbeiten.findstr
Dokumentation wird angegeben, dass dasstrings
Teil NICHT optional ist und dass Sie es nach den optionalen Attributen und vor der Liste der optionalen Dateinamen platzieren müssen. Wenn "Ihr gefunden" darin besteht, dass die Verwendung eines Befehls ohne Befolgung seines Verwendungsformats einen Fehler verursacht, ist ein solcher Punkt gut dokumentiert. Siehe Befehlssyntax : "Die Syntax wird in der Reihenfolge angezeigt, in der Sie einen Befehl und alle darauf folgenden Parameter