Quelles sont les fonctionnalités et limitations non documentées de la commande Windows FINDSTR?

Les arguments / options ont priorité sur la redirection, qui a priorité sur les données diffusées.

Les arguments de nom de fichier et /F:file peuvent être combinés. Plusieurs arguments de nom de fichier peuvent être utilisés. Si plusieurs options de /F:file sont spécifiées, seul le dernier est utilisé. Les caractères génériques sont autorisés dans les arguments de nom de fichier, mais pas dans le fichier désigné par /F:file .

Source des chaînes de recherche (mise à jour basée sur des tests sous Windows 7)
Les options /G:file et /C:ssortingng peuvent être combinées. Multiple /C:ssortingng options de /C:ssortingng peuvent être spécifiées. Si plusieurs options de /G:file sont spécifiées, seul le dernier est utilisé. Si l'un des /G:file ou /C:ssortingng est utilisé, tous les arguments autres que les options sont supposés être des fichiers à rechercher. Si ni /G:file ni /C:ssortingng n'est utilisé, le premier argument non-option est traité comme une liste de termes de recherche délimitée par des espaces.

Les noms de fichiers ne doivent pas être cités dans le fichier lorsque vous utilisez l'option /F:FILE .
Les noms de fichiers peuvent contenir des espaces et d'autres caractères spéciaux. La plupart des commandes exigent que ces noms de fichiers soient cités. Mais l'option FINDSTR /F:files.txt requirejs que les noms de fichiers dans files.txt ne doivent PAS être cités. Le fichier ne sera pas trouvé si le nom est cité.

BOGUE - Les noms de fichiers courts 8.3 peuvent casser les options /D et /S
Comme avec toutes les commandes Windows, FINDSTR essaiera de faire correspondre le nom long et le nom abrégé 8.3 lors de la recherche de fichiers à rechercher. Supposons que le dossier actuel contient les fichiers non vides suivants:

 b1.txt b.txt2 c.txt 

La commande suivante trouvera tous les 3 fichiers avec succès:

 findstr /m "^" *.txt 

b.txt2 correspond car le nom court correspondant B9F64~1.TXT correspond. Ceci est cohérent avec le comportement de toutes les autres commandes Windows.

Mais un bogue avec les options /D et /S entraîne les commandes suivantes uniquement pour trouver b1.txt

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

Le bogue empêche la b.txt2 de b.txt2 , ainsi que tous les noms de fichiers qui sortingent après b.txt2 dans le même répertoire. Des fichiers supplémentaires qui sont a.txt auparavant, comme a.txt , sont trouvés. Les fichiers supplémentaires d.txt plus tard, comme d.txt , sont manqués une fois le bogue déclenché.

Chaque répertoire recherché est traité indépendamment. Par exemple, l’option /S commencerait avec succès la recherche dans un dossier enfant après l’échec de la recherche des fichiers dans le parent, mais une fois que le bogue provoquera un manque de nom de fichier dans l’enfant, tous les fichiers ultérieurs de ce dossier manquer.

Les commandes fonctionnent sans bogue si les mêmes noms de fichiers sont créés sur une machine sur laquelle la génération de noms NTFS 8.3 est désactivée. Bien sûr, b.txt2 ne serait pas trouvé, mais c.txt serait trouvé correctement.

Tous les noms courts ne déclenchent pas le bogue. Toutes les instances de comportement buggé que j'ai vues impliquent une extension de plus de 3 caractères avec un nom court 8.3 qui commence comme un nom normal qui ne nécessite pas de nom 8.3.

Le bogue a été confirmé sur XP, Vista et Windows 7.

Caractères non imprimables et option /P
L'option /P oblige FINDSTR à ignorer tout fichier contenant l'un des codes d'octet décimal suivants:
0-7, 14-25, 27-31.

En d'autres termes, l'option /P ignore uniquement les fichiers contenant des caractères de contrôle non imprimables. Les caractères de contrôle sont des codes inférieurs ou égaux à 31 (0x1F). FINDSTR traite les caractères de contrôle suivants comme imprimables:

  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) 

Tous les autres caractères de contrôle sont traités comme non imprimables, la présence de ceux-ci entraînant l’option /P pour ignorer le fichier.

Les entrées canalisées et redirigées peuvent avoir ajouté
Si l'entrée est redirigée et que le dernier caractère du stream n'est pas , alors FINDSTR ajoute automatiquement à l'entrée. Cela a été confirmé sur XP, Vista et Windows 7. (Je pensais que le tube Windows était responsable de la modification de l'entrée, mais j'ai depuis découvert que FINDSTR est en train de faire la modification.)

La même chose est vraie pour les entrées redirigées sur Vista. Si le dernier caractère d'un fichier utilisé comme entrée redirigée n'est pas , alors FINDSTR ajoute automatiquement à l'entrée. Cependant, XP et Windows 7 ne modifient pas les entrées redirigées.

FINDSTR se bloque sur XP et Windows 7 si l’entrée redirigée ne se termine pas par
C'est une "fonctionnalité" désagréable sur XP et Windows 7. Si le dernier caractère d'un fichier utilisé comme entrée redirigée ne se termine pas par , alors FINDSTR se bloquera indéfiniment une fois qu'il atteindra la fin du fichier redirigé.

La dernière ligne de données canalisées peut être ignorée si elle consiste en un seul caractère
Si l'entrée est redirigée et que la dernière ligne est constituée d'un seul caractère qui n'est pas suivi par , alors FINDSTR ignore complètement la dernière ligne.

Exemple - La première commande avec un seul caractère et sans ne correspond pas, mais la deuxième commande avec 2 caractères fonctionne correctement, de même que la troisième commande comportant un caractère avec terminaison de ligne.

 > set /p "=x"  set /p "=xx"  echo x| findstr "^" x 

Signalé par l'utilisateur DosTips Sponge Belly au nouveau bug findstr . Confirmé sur XP, Windows 7 et Windows 8. Je n'ai pas encore entendu parler de Vista. (Je n'ai plus Vista à tester).

Syntaxe d'option
Les options peuvent être préfixées par / ou - options peuvent être concaténées après un seul / ou - . Cependant, la liste d'options concaténée peut contenir au plus une option multi-caractères telle que OFF ou F: et l'option multi-caractères doit être la dernière option de la liste.

Les méthodes suivantes permettent d'exprimer une recherche d'expression rationnelle insensible à la casse pour toute ligne contenant à la fois "salut" et "au revoir" dans n'importe quel ordre.

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

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

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

Limites de longueur de la chaîne de recherche
Sur Vista, la longueur maximale autorisée pour une seule chaîne de recherche est de 511 octets. Si une chaîne de recherche dépasse 511, le résultat est une FINDSTR: Search ssortingng too long. erreur avec ERRORLEVEL 2.

Lorsque vous effectuez une recherche d'expression régulière, la longueur maximale de la chaîne de recherche est 254. Une expression régulière d'une longueur comprise entre 255 et 511 entraîne une FINDSTR: Out of memory avec ERRORLEVEL 2. Une longueur d'expression régulière> 511 entraîne la recherche FINDSTR: Search ssortingng too long. Erreur.

Sur Windows XP, la longueur de la chaîne de recherche est apparemment plus courte. Erreur Findstr: "Chaîne de recherche trop longue": Comment extraire et faire correspondre une sous-chaîne dans une boucle "for"? La limite de XP est de 127 octets pour les recherches littérales et rationnelles.

Limites de longueur de ligne
Les fichiers spécifiés en tant qu'argument de ligne de commande ou via l'option / F: FILE n'ont aucune limite de longueur de ligne connue. Les recherches ont été exécutées avec succès sur un fichier de 128 Mo qui ne contenait pas un seul .

Les données canalisées et les entrées redirigées sont limitées à 8191 octets par ligne. Cette limite est une "fonctionnalité" de FINDSTR. Ce n'est pas inhérent aux tuyaux ou à la redirection. FINDSTR utilisant une entrée stdin redirigée ou une entrée redirigée ne correspondra à aucune ligne> = 8k octets. Les lignes> = 8k génèrent un message d'erreur à stderr, mais ERRORLEVEL est toujours à 0 si la chaîne de recherche est trouvée dans au moins une ligne d'au moins un fichier.

Type de recherche par défaut: expression littérale vs expression régulière
/C:"ssortingng" - La valeur par défaut est / L literal. Combiner explicitement l'option / L avec / C: "ssortingng" fonctionne certes, mais est redondante.

"ssortingng argument" - La valeur par défaut dépend du contenu de la toute première chaîne de recherche. (N'oubliez pas que est utilisé pour délimiter les chaînes de recherche.) Si la première chaîne de recherche est une expression régulière valide contenant au moins un méta-caractère non échappé, toutes les chaînes de recherche sont traitées comme des expressions régulières. Sinon, toutes les chaînes de recherche sont traitées comme des littéraux. Par exemple, "51.4 200" sera traité comme deux expressions régulières car la première chaîne contient un point non échappé, tandis que "200 51.4" sera traité comme deux littéraux car la première chaîne ne contient aucun méta-caractère.

/G:file - La valeur par défaut dépend du contenu de la première ligne non vide du fichier. Si la première chaîne de recherche est une expression régulière valide contenant au moins un méta-caractère non échappé, toutes les chaînes de recherche sont traitées comme des expressions régulières. Sinon, toutes les chaînes de recherche sont traitées comme des littéraux.

Recommandation - Toujours spécifier explicitement l'option /L option littérale ou l'option /R expression régulière lors de l'utilisation de "ssortingng argument" ou /G:file .

BOGUE - Spécifier plusieurs chaînes de recherche littérale peut donner des résultats peu fiables

L'exemple FINDSTR simple suivant ne parvient pas à trouver une correspondance, même si elle le devrait.

 echo ffffaaa|findstr /l "ffffaaa faffaffddd" 

Ce bogue a été confirmé sur Windows Server 2003, Windows XP, Vista et Windows 7.

Sur la base d'expériences, FINDSTR peut échouer si toutes les conditions suivantes sont remplies:

• La recherche utilise plusieurs chaînes de recherche littérale
• Les chaînes de recherche sont de différentes longueurs
• Une courte chaîne de recherche se chevauche avec une chaîne de recherche plus longue
• La recherche est sensible à la casse (option non /I )

À chaque échec que j'ai vu, c'est toujours l'une des chaînes de recherche les plus courtes qui échouent.

Pour plus d'informations, voir Pourquoi cet exemple FINDSTR avec plusieurs chaînes de recherche littérale ne trouve-t-il pas une correspondance?

Citations et slashs dans les arguments de la ligne de commande - Note:
Les informations contenues dans cette section en surbrillance ne sont pas exactes à 100%. Après avoir écrit cette section, l'utilisateur MC ND m'a indiqué une référence documentant comment la bibliothèque Microsoft C / C ++ parsing les parameters . C'est horriblement compliqué, mais il semble prédire avec précision les barres obliques inverses et les règles de cotation pour les arguments de la ligne de commande FINDSTR. Je vous recommande d'utiliser les informations surlignées ci-dessous comme guide, mais si vous souhaitez des informations plus précises, reportez-vous au lien.

Citation échappée dans les chaînes de recherche de ligne de commande
Les guillemets dans les chaînes de recherche de ligne de commande doivent être précédés d'une barre oblique inversée telle que \" . Cela est vrai pour les chaînes de recherche littérale et regex. Ces informations ont été confirmées sur XP, Vista et Windows 7.

Remarque: Le devis peut également devoir être échappé pour l'parsingur CMD.EXE, mais cela n'a rien à voir avec FINDSTR. Par exemple, pour rechercher un seul devis, vous pouvez utiliser:

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

Échapper à la barre oblique inverse dans les chaînes de recherche littérale de ligne de commande
La barre oblique inverse dans une chaîne de recherche littérale peut normalement être représentée par \ ou par \\ . Ils sont généralement équivalents. (Il peut y avoir des cas inhabituels dans Vista où la barre oblique inverse doit toujours être échappée, mais je n'ai plus de machine Vista à tester) .

Mais il y a des cas particuliers:

Lors de la recherche de barres obliques inverses consécutives, toutes les exceptions sauf la dernière doivent être évitées. Le dernier backslash peut éventuellement être échappé.

• \\ peut être codé comme \\\ ou \\\\
• \\\ peut être codé comme \\\\\\ ou \\\\\\

Rechercher une ou plusieurs barres obliques inverses avant qu'une citation ne soit bizarre. La logique suggérerait que la citation doit être échappée, et chacune des barres obliques inverses principales devrait être échappée, mais cela ne fonctionne pas! Au lieu de cela, chacune des barres obliques inverses doit être échappée deux fois et le devis est échappé normalement:

• \" doit être codé comme \\\\\"
• \\" doit être codé comme \\\\\\\\\"

Comme indiqué précédemment, un ou plusieurs guillemets évités peuvent également nécessiter une échappée avec ^ pour l'parsingur CMD.

Les informations de cette section ont été confirmées sur XP et Windows 7.

Échapper à la barre oblique inverse dans les chaînes de recherche de regex en ligne de commande

• Vista uniquement: la barre oblique inverse dans une regex doit être soit double échappée comme \\\\ , soit simple échappée dans un jeu de classes de caractères comme [\\]

• XP et Windows 7: la barre oblique inverse dans une expression régulière peut toujours être représentée par [\\] . Il peut normalement être représenté par \\ . Mais cela ne fonctionne jamais si la barre oblique inverse précède une citation échappée.

  Une ou plusieurs barres obliques inverses avant qu'un guillemet échappé doive soit être échappé double, soit être codé comme [\\]

  • \" peut être codé comme \\\\\" ou [\\]\"
  • \\" peut être codé comme \\\\\\\\\" ou [\\][\\]\" ou \\[\\]\"

Citation et barre oblique inversée dans / G: chaînes de recherche littérale FILE
Les guillemets et les barres obliques inverses dans un fichier de chaîne de recherche littéral spécifié par / G: file ne doivent pas être échappés, mais ils peuvent l'être.

" et \" sont équivalents.

\ et \\ sont équivalents.

Si l'intention est de trouver \\, alors au moins la barre oblique inverse doit être échappée. Les deux \\\ et \\\\ fonctionnent.

Si l'intention est de trouver \ ", alors au moins la barre oblique inversée doit être échappée. Les deux \\" et \\\" fonctionnent.

Échappement à la cotation et à la barre oblique inverse dans / G: chaînes de recherche de regex FILE
C'est le seul cas où les séquences d'échappement fonctionnent comme prévu en fonction de la documentation. Quote n'est pas un métacaractère de regex, il n'a donc pas besoin d'être échappé (mais peut l'être). La barre oblique inverse est un métacaractère de regex, il doit donc être échappé.

Limites de caractères pour les parameters de ligne de commande - Transformation ASCII étendue
Le caractère nul (0x00) ne peut apparaître dans aucune chaîne de la ligne de commande. Tout autre caractère simple octet peut apparaître dans la chaîne (0x01 - 0xFF). Toutefois, FINDSTR convertit de nombreux caractères ASCII étendus trouvés dans les parameters de ligne de commande en d'autres caractères. Cela a un impact majeur de deux manières:

1) De nombreux caractères ASCII étendus ne correspondront pas s'ils sont utilisés comme chaîne de recherche sur la ligne de commande. Cette limitation est la même pour les recherches littérales et rationnelles. Si une chaîne de recherche doit contenir un code ASCII étendu, l'option /G:FILE doit être utilisée à la place.

2) FINDSTR peut ne pas trouver de fichier si le nom contient des caractères ASCII étendus et si le nom du fichier est spécifié sur la ligne de commande. Si un fichier à rechercher contient un nom ASCII étendu, l'option /F:FILE doit être utilisée à la place.

Voici une liste complète des transformations de caractères ASCII étendues que FINDSTR exécute sur les chaînes de lignes de commande. Chaque caractère est représenté par la valeur du code octet décimal. Le premier code représente le caractère fourni sur la ligne de commande et le second code représente le caractère dans lequel il est transformé. Remarque - cette liste a été compilée sur une machine américaine. Je ne sais pas quel impact d'autres langues peuvent avoir sur cette liste.

 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 

Tout caractère> 0 ne figurant pas dans la liste ci-dessus est traité comme tel, y compris et < LF> . La méthode la plus simple pour inclure des caractères impairs comme et consiste à les placer dans une variable d’environnement et à utiliser l’expansion retardée dans l’argument de la ligne de commande.

Limites de caractères pour les chaînes trouvées dans les fichiers spécifiés par les options / G: FILE et / F: FILE
Le caractère nul (0x00) peut apparaître dans le fichier, mais il fonctionne comme le terminateur de chaîne C. Tous les caractères après un caractère nul sont traités comme une chaîne différente comme s'ils étaient sur une autre ligne.

Les caractères et sont traités comme des terminateurs de ligne qui terminent une chaîne et ne sont pas inclus dans la chaîne.

Tous les autres caractères à un octet sont parfaitement inclus dans une chaîne.

Recherche de fichiers Unicode
FINDSTR ne peut pas rechercher correctement la plupart des Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32) car il ne peut rechercher aucun octet et Unicode contient généralement de nombreux octets nuls.

Cependant, la commande TYPE convertit UTF-16LE avec la nomenclature en un jeu de caractères à un seul octet. Par conséquent, une commande comme celle-ci fonctionnera avec UTF-16LE avec la nomenclature.

 type unicode.txt|findstr "search" 

Notez que les points de code Unicode qui ne sont pas pris en charge par votre page de code active seront convertis en ? personnages.

Il est possible de rechercher UTF-8 tant que votre chaîne de recherche contient uniquement des caractères ASCII. Cependant, la sortie de la console de tous les caractères multi-octets UTF-8 ne sera pas correcte. Mais si vous redirigez la sortie vers un fichier, le résultat sera correctement encodé en UTF-8. Notez que si le fichier UTF-8 contient une nomenclature, la nomenclature sera considérée comme faisant partie de la première ligne, ce qui pourrait déclencher une recherche correspondant au début d'une ligne.

Il est possible de rechercher des caractères multi-octets UTF-8 si vous placez votre chaîne de recherche dans un fichier de recherche encodé en UTF-8 (sans nomenclature) et utilisez l'option / G.

Fin de ligne
FINDSTR rompt les lignes immédiatement après chaque . La présence ou l'absence de n'a aucun impact sur les sauts de ligne.

Recherche à travers des sauts de ligne
Comme prévu, le . le métacaractère de regex ne correspondra pas à ou . Mais il est possible d'effectuer une recherche sur un saut de ligne en utilisant une chaîne de recherche par ligne de commande. Les caractères et doivent être identifiés explicitement. Si une correspondance multi-lignes est trouvée, seule la première ligne du match est imprimée. FINDSTR double alors à la deuxième ligne de la source et recommence la recherche - une sorte de fonctionnalité de type "regarder en avant".

Supposons que TEXT.TXT a ce contenu (peut être un style Unix ou Windows)

 A A A B A A 

Alors ce script

 @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 

donne ces résultats

 1:A 2:A 5:A 

La recherche sur les sauts de ligne à l'aide de l'option / G: FILE est imprécise car la seule manière de faire correspondre ou est via une expression de plage de classes de caractères regex qui prend en charge les caractères EOL.

• [-<0x0B>] correspond à , mais il correspond également à et <0x0B>

• [<0x0C>-!] , mais il correspond également à <0x0C> et!

  Remarque - les éléments ci-dessus sont des représentations symboliques du stream d'octets regex, car je ne peux pas représenter graphiquement les caractères.

Réponse continue dans la partie 2 ci-dessous ...