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

préface

une grande partie de l'information contenue dans cette réponse a été recueillie à partir d'expériences réalisées sur une machine Vista. Sauf mention contraire explicite, je n'ai pas confirmé si l'information s'applique à d'autres versions de Windows.

sortie FINDSTR

La documentation ne dérange jamais pour expliquer la sortie de FINDSTR. Il fait allusion au fait que les lignes correspondantes sont imprimées, mais rien de plus.

le format de sortie de la ligne correspondante est le suivant:

nom du fichier: lineNumber: lineOffset: text

où

nom du fichier: = le nom du fichier contenant le correspondance de la ligne. Le nom du fichier n'est pas imprimé si la requête était explicitement pour un seul fichier, ou si la recherche a été faite par piped input ou redirigée input. Une fois imprimé, le nom du fichier inclura toujours toute information de chemin fournie. Des informations supplémentaires sur le chemin seront ajoutées si l'option /S est utilisée. L'imprimé chemin est toujours par rapport à la condition chemin, ou relatif au répertoire courant si aucune condition.

Note - le préfixe du nom de fichier peut être évité lorsque recherche de plusieurs fichiers à l'aide des caractères génériques non standard (et mal documentés) < et > . Les règles exactes pour le fonctionnement de ces caractères génériques peuvent être trouvées ici . Enfin, vous pouvez regarder cet exemple de la façon dont les caractères génériques non standard fonctionnent avec FINDSTR .

numéro de ligne: = le numéro de ligne du ligne correspondante représentée par une valeur décimale avec 1 représentant la première ligne de l'entrée. Seulement imprimé si l'option /N est spécifiée.

lineOffset: = décalage décimal du début de la ligne correspondante, avec 0 représentant le 1er caractère de la première ligne. Seulement imprimé si l'option /O est spécifiée. C'est et non le décalage du match à l'intérieur de la ligne. C'est le nombre d'octets à partir du début du fichier pour le début de la ligne.

text = représentation binaire de la ligne correspondante, y compris tout <CR> et/ou <LF>. Rien n'est laissé de côté de la sortie binaire, de sorte que cet exemple qui correspond à toutes les lignes produira une copie binaire exacte du fichier original.

FINDSTR "^" FILE >FILE_COPY

Plus de contrôle les caractères et de nombreux caractères ASCII étendus s'affichent sous forme de points sur XP

FINDSTR sur XP affiche la plupart des caractères de contrôle non imprimables à partir des lignes correspondantes comme des points (périodes) sur l'écran. Les caractères de contrôle suivants sont des exceptions; ils s'affichent comme eux - mêmes: 0x09 Tab, 0x0A LineFeed, 0x0b Vertical Tab, 0x0c form Feed, 0x0D Carriage Return.

XP FINDSTR convertit aussi un certain nombre de caractères ASCII étendus en points. Les caractères ASCII étendus qui s'affichent sous forme de points sur XP sont les mêmes que ceux qui sont transformés lorsqu'ils sont fournis sur la ligne de commande. Voir la section "Character limits for command line parameters-Extended ASCII transformation " , plus loin dans ce post

Les caractères de contrôle

et les ASCII étendus ne sont pas convertis en points sur XP si la sortie est pipée, redirigée vers un fichier, ou dans une clause FOR IN ().

Vista et Windows 7 affiche toujours tous les caractères comme eux-mêmes, jamais comme des points.

Return Codes (ERRORLEVEL))

• 0 (succès) La correspondance
  • a été trouvée dans au moins une ligne d'au moins un fichier.
• 1 (défaillance)
  • aucune correspondance n'a été trouvée dans aucune ligne d'un fichier.
  • couleur non valide spécifiée par /A:xx option
• 2 (Erreur)
  • options incompatibles /L et /R toutes deux spécifiées
  • argument manquant après /A: , /F: , /C: , /D: , ou /G:
  • fichier spécifié par /F:file ou /G:file non trouvé
• 255 (erreur)
  • trop d'expressions régulières termes de la classe de caractères
    
    voir Regex character class term limit and BUG dans la partie 2 de la réponse

Source de données pour la recherche (mise à jour basée sur des tests avec Windows 7)

Findstr peut rechercher des données à partir d'une seule des sources suivantes:

• noms de fichiers spécifiés comme arguments et/ou en utilisant l'option /F:file .

• stdin via la redirection de findstr "searchString" <file

• flux de données à partir d'un tuyau type file | findstr "searchString"

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

Les arguments

et /F:file peuvent être combinés. Plusieurs arguments de nom de fichier peuvent être utilisés. Si plusieurs options /F:file sont spécifiées, alors seule la dernière est utilisée. Les jokers sont autorisés dans les arguments nom de fichier, mais pas dans le fichier pointé par /F:file .

Source des chaînes de recherche (mis à jour sur la base d'essais avec Windows 7)

Les options /G:file et /C:string peuvent être combinées. Plusieurs options /C:string peuvent être spécifiées. Si plusieurs options /G:file sont spécifiées, alors seule la dernière est utilisée. Si /G:file ou /C:string est utilisé, alors tous les arguments non-optionnels sont considérés comme des fichiers à rechercher. Si ni /G:file ni /C:string n'est utilisé, alors la première non-option l'argument est traité comme une liste délimitée par un espace des termes de recherche.

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 /F:files.txt de FINDSTR exige que les noms de fichiers se trouvent dans les fichiers.txt ne doit pas être cité. Le fichier ne sera pas trouvé, si le nom est citer.

BUG - Court 8.3 les noms de fichiers peuvent briser le /D et /S options

Comme pour toutes les commandes Windows, FINDSTR tentera de faire correspondre à la fois le nom long et le nom court 8.3 lors de la recherche de fichiers à rechercher. Supposons que le dossier courant contient les fichiers non vides suivants:

b1.txt
b.txt2
c.txt

la commande suivante va trouver avec succès les 3 fichiers:

findstr /m "^" *.txt

b.txt2 correspond parce que le nom court correspondant B9F64~1.TXT correspond. Ceci est compatible avec le comportement de toutes les autres commandes Windows.

mais un bug avec les options /D et /S fait que les commandes suivantes ne trouvent que b1.txt

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

le bug empêche b.txt2 d'être trouvé, ainsi que tous les noms de fichiers qui trient après b.txt2 dans le même répertoire. Des fichiers supplémentaires qui trient avant, comme a.txt , sont trouvés. Les fichiers supplémentaires qui trient plus tard, comme d.txt , sont manqués une fois que le bogue a été 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 avoir échoué à trouver des fichiers dans le parent, mais une fois que le bogue provoque un nom de fichier court à manquer dans l'enfant, puis tous les fichiers suivants dans ce dossier enfant seraient également manqués.

les commandes fonctionnent sans bogue si les mêmes noms de fichiers sont créés sur une machine dont 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 de bugged que j'ai vu impliquent une extension qui est plus longue que 3 caractères avec un nom court 8.3 qui commence de la même façon qu'un nom normal qui ne nécessite pas un nom 8.3.

le bug a été confirmé sur XP, Vista, et Windows 7.

caractères Non imprimables et /P option

L'option /P fait sauter à FINDSTR tout fichier qui contient l'un des codes décimaux suivants:

0-7, 14-25, 27-31.

Put d'une autre manière, l'option /P ne sautera que les fichiers qui contiennent 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 laquelle provoque l'option /P pour sauter le fichier.

les entrées canalisées et redirigées peuvent avoir <CR><LF> applied

Si l'entrée est pipée et que le dernier caractère du flux n'est pas <LF> , alors FINDSTR ajoutera automatiquement <CR><LF> à l'entrée. Ceci a été confirmé sur XP, Vista et Windows 7. (j'avais l'habitude de penser que la pipe Windows était responsable de la modification de l'entrée, mais j'ai depuis découvert que FINDSTR fait réellement la modification.)

le il en va de même 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 <LF> , alors FINDSTR ajoutera automatiquement <CR><LF> à 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 redirigé entrée ne prend pas fin avec <LF>

C'est une vilaine "fonctionnalité" sur XP et Windows 7. Si le dernier caractère de un fichier utilisé comme entrée redirigée ne se termine pas avec <LF> , alors FINDSTR sera suspendu indéfiniment une fois qu'il atteint la fin du fichier redirigé.

la dernière ligne de données canalisées peut être ignorée si elle est constituée d'un seul caractère

Si L'entrée est pipée et que la dernière ligne se compose d'un seul caractère qui n'est pas suivi de <LF> , alors FINDSTR ignore complètement la dernière ligne.

exemple-la première commande avec un seul caractère et pas de <LF> ne correspond pas, mais la deuxième commande avec 2 caractères fonctionne bien, comme le fait la troisième commande qui a un caractère avec terminaison newline.

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

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

> echo x| findstr "^"
x

Rapporté par DosTips utilisateur Éponge Ventre nouvelle findstr bug . Confirmé sur XP, Windows 7 et Windows 8. Je n'ai pas encore entendu parler de Vista. (Je n'ai plus de Vista à tester).

syntaxe D'Option

Les Options peuvent être préfixées avec / ou - Les 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 multicaractère telle que OFF ou F:, et l'option multicaractère doit être la dernière option de la liste.

suivantes sont équivalentes façons d'exprimer un cas insensible recherche regex pour n'importe quelle ligne qui contient à la fois "hello" et "goodbye" 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"

Sur Vista La longueur maximale permise pour une chaîne de recherche simple est de 511 octets. Si une chaîne de recherche dépasse 511, alors le résultat est une erreur FINDSTR: Search string too long. avec ERRORLEVEL 2.

pour une recherche d'expression régulière, la longueur maximale de la chaîne de recherche est 254. Une expression régulière avec une longueur entre 255 et 511 résultera en une erreur FINDSTR: Out of memory avec ERRORLEVEL 2. Une longueur d'expression régulière >511 entraîne l'erreur FINDSTR: Search string too long. .

sur Windows XP la longueur de la chaîne de recherche est apparemment plus courte. Findstr d'erreur: "la Recherche d'une chaîne trop longue": Comment extraire et de correspondance de sous-chaîne dans la boucle "for"? La limite de XP est de 127 octets pour les recherches littérales et regex.

limites de longueur de ligne

Les fichiers spécifiés comme argument de ligne de commande ou via l'option /f:FILE n'ont pas de limite de longueur de ligne connue. Les recherches ont été effectuées avec succès contre 128MB fichier qui ne contient pas un seul .

données acheminées et entrées redirigées est limité à 8191 octets par ligne. Cette limite est une "caractéristique" de FINDSTR. Il n'est pas inhérent aux pipes ou à la redirection. FINDSTR utilisant STDIN redirigé ou entrée pipée ne correspondra jamais à aucune ligne qui est >=8K bytes. Lines >= 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: littéral vs Expression régulière

/C:"string" - the default is / L literal. Combiner explicitement l'option / L avec /C:"string" fonctionne certainement mais est redondant.

"string argument" - La valeur par défaut dépend du contenu de la première chaîne de recherche. (rappelez-vous que est utilisé pour délimiter les chaînes de recherche.) si la première chaîne de recherche est une régulière valide expression qui contient au moins un méta-caractère non échappé, alors 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 littérales. Par exemple, "51.4 200" sera traité comme deux expressions régulières parce que la première chaîne contient un point non échappé, tandis que "200 51.4" sera traité comme deux littérales parce que la première chaîne ne contient pas de méta-caractères.

/G:file - La valeur par défaut dépend de la le contenu de la première ligne non vide dans le fichier. Si la première chaîne de recherche est une expression régulière valide qui contient au moins un méta-caractère non échappé, alors 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 littérales.

recommandation - toujours spécifier explicitement /L option littérale ou /R option d'expression régulière en utilisant "string argument" ou /G:file .

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

l'exemple simple suivant de FINDSTR ne trouve pas de correspondance, même si elle devrait.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

ce bug a été confirmé sur Windows Server 2003, Windows XP, Vista et Windows 7.

basé sur des expériences, FINDSTR peut échouer si tous les les conditions suivantes sont remplies:

• la recherche utilise plusieurs chaînes de recherche littérale
• Les chaînes de recherche sont de longueurs différentes
• une chaîne de recherche courte a un certain degré de chevauchement avec une chaîne de recherche plus longue
• la recherche est sensible à la casse (pas d'option /I )

dans chaque échec que j'ai vu, il est toujours l'un des des chaînes de recherche 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?

guillemets et backslahses dans les arguments en ligne de commande-Note:

L'information contenue dans cette section en surbrillance n'est pas exacte à 100%. Après avoir écrit ceci section, l'utilisateur MC ND m'a indiqué une référence qui documente comment la bibliothèque Microsoft C/C++ se comporte les paramètres . Il est terrifiant compliqué, mais il semble prédire avec précision les règles backslash et quote pour les arguments en ligne de commande FINDSTR. Je vous recommandons d'utiliser les informations ci-dessous comme guide, mais si vous voulez des informations plus précises, se référer au lien.

échapper citation dans la ligne de commande chaînes de recherche

les guillemets dans les chaînes de recherche en ligne de commande doivent être échappés avec des antislash comme \" . Ceci est vrai pour les chaînes de recherche littérale et regex. Ce l'information a été confirmée sur XP, Vista, et Windows 7.

Note: La citation peut également devoir être évitée pour le CMD.EXE parser, mais ça n'a rien à voir avec FINDSTR. Par exemple, pour rechercher un apostrophe, vous pourriez utiliser:

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

barre Oblique inverse d'Échappement à l'intérieur de la ligne de commande littérale des chaînes de recherche

barre Oblique inverse dans un littéral chaîne de recherche peut normalement être représenté comme \ ou \ . Ils sont généralement équivalent. (il peut y avoir des cas à Vista où le revers doit toujours être échappé, mais je ne plus longtemps avoir une machine Vista à l'essai) .

mais il y a quelques cas particuliers:

lors de la recherche de backslashs consécutifs, tous sauf le dernier doit être échapper. Le dernier revers peut éventuellement être échappé.

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

la recherche d'un ou de plusieurs antislashs avant une citation est bizarre. Logique suggère que la citation doit être échappé, et chacun des principaux backslashs devrait être échappé, mais cela ne fonctionne pas! Plutôt, chacun des backslashs principaux doit être double échappée, et la citation s'échappe normalement:

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

comme nous l'avons noté précédemment, une ou plusieurs citations évadées peuvent également nécessiter une fuite avec ^ pour le CMD parser

les informations dans cette section ont été confirmées sur XP et Windows 7.

barre Oblique inverse d'Échappement à l'intérieur de la ligne de commande regex chaînes de recherche

• Vista: barre Oblique inverse dans une regex doit être soit double échappé comme \\ , ou bien seul échappé au sein d'une classe de caractères définie comme [\]

• XP et Windows 7: Backslash dans un regex peut toujours être représenté comme [\] . Elle peut normalement être représentée par \ . Mais ce n'a jamais fonctionne si le revers précède un échappé à la citation.

  un ou plusieurs backslashs avant une citation échappée doit être double échappée, ou alors codée comme [\]

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

escapade Quote and Backlash within / G:FILE literal search strings

Les guillemets et les antislashes indépendants dans un fichier de recherche littéral spécifié par /G:file n'ont pas besoin d'être échappés, mais ils peuvent l'être.

" et \" sont équivalents.

\ et \ sont équivalents.

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

si l'intention est de trouver\", alors au moins le premier revers doit être échappé. Les deux \" et \\" travail.

s'Échappant de Devis et de barre Oblique inverse à l'intérieur de /G:FICHIER regex chaînes de recherche

C'est le seul cas où les séquences d'échappement fonctionnent comme prévu sur la base de la documentation. Devis pas un metacharacter regex, donc il n'a pas besoin d'être échappé (mais peut l'être). Backslash est un metacharacter regex, donc il doit être échappé.

la limite de Caractères pour les paramètres de ligne de commande - ASCII Étendu transformation

Le caractère nul (0x00) ne peut apparaître dans aucune chaîne sur la ligne de commande. N'importe quel autre caractère d'octet simple peut apparaître dans la chaîne de caractères (0x01 - 0xFF). Cependant, FINDSTR convertit de nombreux caractères ASCII étendus il trouve dans les paramètres de la ligne de commande d'autres caractères. Cela a un impact majeur de deux façons:

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 regex. Si une chaîne de recherche doit contenir un ASCII étendu, l'option /G:FILE doit être utilisée à la place.

2) FINDSTR peut ne parviennent pas à trouver un fichier si le nom contient des étendues Les caractères ASCII et le nom du fichier sont spécifiés sur la ligne de commande. Si un fichier à rechercher contient des ASCII étendus dans le nom, 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 des chaînes de lignes de commande. Chaque caractère est représenté par le code décimal. Le premier code représente le caractère tel que fourni sur la ligne de commande, et le deuxième code représente le personnage est transformé en. Note-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 <CR> et LF> . La façon la plus simple d'inclure des caractères impairs comme <CR> et <LF> est de les insérer dans une variable d'environnement et d'utiliser l'expansion retardée dans le argument en ligne de commande.

la limite de Caractères pour les chaînes trouvées dans les fichiers spécifiés par /G:FICHIER et /F:FICHIER options

Le caractère nul (0x00) peut apparaître dans le fichier, mais il fonctionne comme le terminator C string. 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 <CR> et <LF> sont traités comme terminateurs de ligne qui terminent une chaîne, et ne sont pas inclus dans la chaîne.

tous les autres caractères simples sont parfaitement inclus dans une chaîne.

recherche de fichiers Unicode

FINDSTR ne peut pas rechercher correctement la plupart des Unicodes (UTF-16, UTF-16LE, UTF-16BE, UTF-32) parce qu'il ne peut pas rechercher des octets nul et Unicode contient généralement beaucoup nul octets.

cependant, la commande TYPE convertit UTF-16LE avec BOM en un seul jeu de caractères octets, ainsi une commande comme celle-ci fonctionnera avec UTF-16LE avec bom.

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 ? caractères.

Il est possibilité de rechercher UTF-8 tant que votre chaîne de recherche ne contient que ASCII. Cependant, la sortie de la console de n'importe quel caractère UTF-8 à plusieurs octets ne sera pas correcte. Mais si vous redirigez la sortie vers un fichier, alors le résultat sera correctement encodé UTF-8. Notez que si le fichier UTF-8 contient un BOM, alors le BOM sera considéré comme faisant partie de la première ligne, ce qui pourrait annuler une recherche qui correspond au début d'une ligne.

il est possible pour rechercher des caractères UTF-8 à plusieurs octets si vous mettez votre chaîne de recherche dans un fichier de recherche encodé UTF-8 (sans BOM), et utilisez l'option /G.

Fin De Ligne

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

la Recherche à travers des sauts de ligne

Comme attendu, le metacharacter regex . ne correspondra pas à ou . Mais il est possible de chercher à travers une rupture de ligne en utilisant une chaîne de recherche en ligne de commande. Les caractères et < LF> doivent être appariés explicitement. Si une correspondance multi-lignes est trouvée, seule la première ligne de la correspondance est imprimée. FINDSTR revient ensuite à la deuxième ligne de la source et recommence la recherche - une sorte de fonction de type "look ahead".

suppose texte.TXT a ces contenu (Unix ou Windows)

A
A
A
B
A
A

puis 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 des sauts de ligne en utilisant l'option /G:FILE est imprécise parce que la seule façon de faire correspondre ou est par l'intermédiaire d'une expression de portée de classe de caractères regex qui Sandwich les caractères EOL.

• [<TAB>-<0x0B>] les allumettes , mais il correspond aussi à < TAB> et <0x0B>

• [<0x0C>-!] correspond à , mais aussi à <0x0C> et !

  Note-ce qui précède sont des représentations symboliques du flux d'octets regex puisque je ne peux pas représenter graphiquement les caractères.

la réponse se poursuit dans la partie 2 ci-dessous...