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

préface
Une grande partie des informations contenues dans cette réponse a été recueillie sur la base d’expériences exécutées sur une machine Vista. Sauf indication contraire explicite, Je n’ai pas confirmé si les informations s’appliquent à d’autres versions de Windows.

findstr output
la documentation ne prend jamais la peine d’expliquer la sortie de FINDSTR. Cela fait allusion au fait que les lignes correspondantes sont imprimées, mais rien de plus.,

Le format de la correspondance de la ligne de sortie est comme suit:

nom du fichier:lineNumber:lineOffset:texte

où

fileName: = Le nom du fichier contenant la correspondance de la ligne. Le nom du fichier n’est pas imprimé si la demande était explicitement pour un seul fichier, ou si la recherche d’une entrée canalisée ou d’une entrée redirigée. Une fois imprimé, le nom de fichier inclura toujours toutes les informations de chemin fournies. Des informations de chemin supplémentaires seront ajoutées si l’option/S est utilisée. Le chemin imprimé est toujours relatif au chemin fourni, ou relatif au répertoire courant si aucun n’est fourni.,

remarque – le préfixe de nom de fichier peut être évité lors de la recherche de plusieurs fichiers en utilisant les 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.

lineNumber: = le numéro de ligne de la ligne correspondante représenté sous la forme d’une valeur décimale avec 1 représentant la 1ère ligne de l’entrée. Imprimé uniquement si l’option /N est spécifiée.,

lineOffset: = le décalage d’octet décimal du début de la ligne correspondante, avec 0 représentant le 1er caractère de la 1ère ligne. Imprimé uniquement si l’option/O est spécifiée. Ce n’est pas le décalage de la correspondance dans la ligne. C’est le nombre d’octets depuis le début du fichier jusqu’au début de la ligne.

texte = La représentation binaire de la mise en correspondance de la ligne, y compris tous <CR> et/ou <LF>., Rien n’est laissé en dehors de la sortie binaire, de sorte que cet exemple qui correspond à toutes les lignes produira une copie binaire exacte du fichier d’origine.

FINDSTR "^" FILE >FILE_COPY

l’option /A définit la couleur du nom de fichier:, lineNumber: et lineOffset: sortie uniquement. Le texte de la ligne correspondante est toujours affiché avec la couleur de la console actuelle. L’option n’a d’effet que lorsque la sortie est affichée directement sur la console. L’option n’a aucun effet si la sortie est redirigée vers un fichier ou les canalisations., Voir l’édition 2018-08-18 dans la réponse D’AACINI pour une description du comportement bogué lorsque la sortie est redirigée vers CON.

La plupart des caractères de contrôle 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 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 Chariot Return.

XP FINDSTR convertit également 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 « Limites de caractères pour les paramètres de ligne de commande-transformation ASCII étendue », plus loin dans cet article

Les caractères de contrôle et l’ASCII étendu ne sont pas convertis en points sur XP si la sortie est canalisée, redirigée vers un fichier ou dans une clause FOR IN ().

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

les Codes de Retour (ERRORLEVEL)

• 0 (succès)
  • Correspondance a été trouvée dans au moins une ligne d’au moins un fichier.
• 1 (défaut)
  • Aucune correspondance n’a été trouvée dans n’importe quelle ligne de n’importe quel fichier.,iv id= »b01f5d4aef »>, /D:, ou /G:
  • fichier spécifié par /F:file ou /G:file introuvable
• 255 (erreur)
  • trop de termes de classe de caractères d’expression régulière
    voir regex character class term limit and bug dans la partie 2 de la réponse

source de données à rechercher (mise à jour basée sur des tests avec Windows 7)
findstr peut rechercher des données à partir div id= »b9a1ba330b »> option.,

stdin via la redirection findstr "searchString" <file

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

les Arguments/options préséance sur la redirection, qui prend la priorité sur les canalisations de donné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 /F:file sont spécifiées, seule la dernière est utilisée. Les jokers sont autorisés dans les arguments de nom de fichier, mais pas dans le fichier pointé par /F:file.,

Source des chaînes de recherche (mise à jour en fonction des tests 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, seule la dernière est utilisée. Si /G:file ou /C:string est utilisé, puis tous les arguments sans options sont supposés être des fichiers à rechercher., Si ni /G:file ni /C:string ne sont utilisés, alors le premier argument non-option est traité comme une liste de termes de recherche délimitée par un espace.

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 entre guillemets. Mais L’option FINDSTR /F:files.txt nécessite que les noms de fichiers dans les fichiers.txt ne doit pas être cité. Le fichier ne sera pas trouvé, si le nom est cité.

BUG – Court 8.,3 les noms de fichiers peuvent casser les options/D Et/S
comme avec 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 actuel contient les fichiers non vides suivants:

b1.txtb.txt2c.txt

la commande suivante trouvera avec succès les 3 fichiers:

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 d’un bug avec la balise /D et /S options causes les commandes suivantes ne trouver b1.txt

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

Le bug empêche b.txt2 trouvé, ainsi que tous les noms de fichier de tri 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 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 avoir échoué à trouver des fichiers dans le parent, mais une fois que le bogue fait manquer un nom de fichier court dans l’enfant, tous les fichiers suivants dans ce dossier enfant seraient également manqués.

Les commandes fonctionnent sans bug 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 buggé que j’ai vues impliquent une extension de plus de 3 caractères avec un nom 8.3 court qui commence de la même manière qu’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 l’option/P
l’option/P fait que FINDSTR ignore tout fichier contenant l’un des codes d’octets décimaux suivants:
0-7, 14-25, 27-31.

autrement dit, l’option/P ne sautera que 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 tab10 0x0A line feed11 0x0B vertical tab12 0x0C form feed13 0x0D carriage return26 0x1A substitute (end of text)

tous les autres caractères de contrôle sont traités comme non imprimables, ce qui entraîne l’option/P pour ignorer le fichier.

les Canalisations et la redirection d’entrée peut avoir <CR><LF> ajouté
Si l’entrée est canalisé dans et le dernier caractère du flux n’est pas <LF>, puis FINDSTR ajoutera automatiquement <CR><LF> à l’entrée. Cela a été confirmé sur XP, Vista et Windows 7., (Je pensais que le tuyau Windows était responsable de la modification de l’entrée, mais j’ai depuis découvert que FINDSTR fait réellement la modification.)

la même chose est vraie pour l’entrée redirigée sur Vista. Si le dernier caractère d’un fichier utilisé comme redirigé entrée n’est pas <LF>, puis FINDSTR ajoutera automatiquement <CR><LF> à l’entrée. Cependant, XP et Windows 7 ne modifient pas l’entrée redirigée.

FINDSTR se bloque sur XP et Windows 7 Si l’entrée redirigée ne se termine pas avec<LF>
Il s’agit d’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 <LF>, FINDSTR se bloque 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 se compose d’un seul caractère
Si l’entrée est canalisée et que la dernière ligne se compose d’un seul caractère qui n’est pas suivi de<LF>, FINDSTR ignore complètement la dernière ligne.,

exemple – la première commande avec un seul caractère et aucun <LF> ne correspond pas, mais la deuxième commande avec 2 caractères fonctionne bien, tout comme la troisième commande qui a un caractère avec retour à la ligne de fin.

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

signalé par L’utilisateur de DosTips Sponge Belly au nouveau bogue findstr. Confirmé sur XP, Windows 7 et Windows 8. Je n’ai pas encore entendu parler de Vista. (Je n’ai plus Vista pour tester).

Option de syntaxe
Option lettres ne sont pas sensibles à la casse, donc /i et /I sont équivalents.,

les Options peuvent être préfixés par / ou -Options peuvent être concaténées après un / ou -. Cependant, la liste d’options concaténées 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.,

Les conditions suivantes sont équivalentes façons d’exprimer une expression régulière insensible à la casse recherchez la ligne qui contient à la fois « bonjour » 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"

Si une chaîne de recherche commence par un / ou - littérale, puis la balise /C ou /G option doit être utilisée. Merci à Stephan de l’avoir signalé dans un commentaire (depuis supprimé).,

Limites de longueur de 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 erreur FINDSTR: Search string too long. avec ERRORLEVEL 2.

lors d’une recherche d’expression régulière, la longueur maximale de la chaîne de recherche est de 254. Une expression régulière avec une longueur comprise entre 255 et 511 entraînera une erreur FINDSTR: Out of memory avec ERRORLEVEL 2. Une expression régulière longueur >511 résultats dans le FINDSTR: Search string too long. erreur.,

sous Windows XP, la longueur de la chaîne de recherche est apparemment plus courte. Findstr error: « Search string too long »: comment extraire et faire correspondre une sous-chaîne dans la boucle » for »?La limite XP est de 127 octets pour les recherches littérales et regex.

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 pas de 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 <LF>.

Les données canalisées et L’entrée redirigée 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 l’entrée STDIN ou canalisée redirigée ne correspondra jamais à une ligne qui est > =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: littéral vs Expression régulière
/C:"string" – la valeur par défaut est / l littéral. La combinaison explicite de l’option /l avec /C: » string  » fonctionne certainement mais est redondante.,

"string argument" – La valeur par défaut dépend du contenu de la première chaîne de recherche. (Rappelez-vous que <espace> 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 qui contient 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 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é, 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 de Toujours préciser /L littérale option ou /R expression régulière option lors de l’utilisation de "string argument" ou /G:file.

la spécification de plusieurs chaînes de recherche littérales peut donner des résultats peu fiables

l’exemple FINDSTR simple suivant ne parvient pas à trouver une correspondance, même s’il le devrait.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

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

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

• La recherche utilise plusieurs chaînes de recherche littérales
• les chaînes de recherche sont de longueurs différentes
• Une chaîne de recherche courte a un certain chevauchement avec une chaîne de recherche plus longue
• La recherche est sensible à p>dans chaque échec que j’ai vu, c’est toujours l’une des chaînes de recherche les plus courtes qui échoue.

  pour plus d’informations, consultez Pourquoi cet exemple FINDSTR avec plusieurs chaînes de recherche littérales ne trouve-t-il pas une correspondance?,

  guillemets et backslahses dans les arguments de ligne de commande
  Remarque – les commentaires de MC Nd De L’utilisateur reflètent les règles horriquement compliquées réelles pour cette section. Il y a 3 phases d’analyse distinctes impliquées:

  • premier cmd.,exe peut exiger que certaines guillemets soient échappés en tant que ^ « (vraiment rien à voir avec FINDSTR)
  • suivant FINDSTR utilise l’analyseur d’arguments MS C/C++ d’avant 2008, qui a des règles spéciales pour  » et \
  • après la fin de l’analyseur d’arguments, FINDSTR traite en outre \ suivi d’un caractère alphanumérique comme littéral, mais \ suivi d’un caractère non alphanumérique comme Il peut servir de guide pour de nombreuses situations, mais les règles ci-dessus sont nécessaires pour une totale compréhension.,

    échappement des guillemets dans les chaînes de recherche en ligne de commande
    Les guillemets dans les chaînes de recherche en ligne de commande doivent être échappés avec une barre oblique inverse comme\". Cela est vrai pour les chaînes de recherche littérales et regex. Cette information a été confirmée sur XP, Vista et Windows 7.

    Remarque: La citation peut également devoir être échappée pour le CMD.Exe parser, mais cela n’a rien à voir avec FINDSTR., Par exemple, pour rechercher une citation unique, vous pouvez utiliser:

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

    échappant à la barre oblique inverse dans les chaînes de recherche littérales de ligne de commande
    La Barre oblique inverse dans une chaîne de recherche littérale peut normalement être représentée comme\ ou comme \\. 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 quelques cas particuliers:

    lors de la recherche de barres obliques inverses consécutives, tous sauf le dernier doivent être enregistrés., La dernière barre oblique inverse peut éventuellement être échappée.

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

    à la Recherche d’une ou plusieurs barres obliques avant une citation est bizarre. Logicwould suggère que la citation doit être échappée, et chacun des leadingbackslashes devrait être échappé, mais cela ne fonctionne pas!, Au lieu de cela,chacun des barres obliques inverses en tête doit être double échappé, et le quoteis échappé normalement:

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

    comme indiqué précédemment, une ou plusieurs guillemets échappés peuvent également nécessiter un échappement avec ^ pour l’analyseur cmd

    les informations de cette section ont été confirmées sous XP et Windows 7.,

    échappant à la barre oblique inverse dans les chaînes de recherche regex de ligne de commande

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

    • XP et une expression régulière peut toujours être représentée sous la forme . Il peut normalement être représenté sous la forme \\. Mais cela ne fonctionne jamais si la barre oblique inverse précède une citation échappée.,aped quote doit soit être échappé, soit codé comme

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

  Escape quote and backslash within /g:file literal search strings
  Les guillemets autonomes et les barres obliques inverses dans un fichier de chaîne de recherche littérale 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 la barre oblique inverse principale doit être échappée. Les deux \\\ et \\\\ le travail.

  Si l’intention est de trouver « , alors au moins la barre oblique inverse principale doit être échappée. Les deux \\" et \\\" le travail.,

  Echapping Quote and Backslash within / G:FILE regex search strings
  c’est le cas où les séquences d’échappement fonctionnent comme prévu sur la base de la documentation. Quote n’est pas un métacaractère regex, il n’a donc pas besoin d’être échappé (mais peut l’être). La barre oblique inverse est un métacaractère regex, il doit donc être échappé.

  Limites de caractères pour les paramètres 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 d’octet unique peut apparaître dans la chaîne (0x01 – 0xFF)., Cependant, FINDSTR convertit de nombreux caractères ASCII étendus qu’il trouve dans les paramètres 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 correspondent 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 pas trouver un fichier si le nom contient des caractères ASCII étendus et que le nom du fichier est spécifié sur la ligne de commande., Si un fichier à rechercher contient un ASCII étendu dans le nom, alors l’option/F:FILE doit être utilisée à la place.

  Voici une liste complète des transformations de caractères ASCII étendues que FINDSTR effectue sur les chaînes de ligne de commande. Chaque caractère est représenté comme la valeur du code octet décimal. Le premier code représente le caractère tel que fourni sur la ligne de commande, et le second code représente le caractère en 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 071169 treated as 170 200 treated as 043 227 treated as 112176 treated as 221 201 treated as 043 228 treated as 083177 treated as 221 202 treated as 045 229 treated as 115178 treated as 221 203 treated as 045 231 treated as 116179 treated as 221 204 treated as 221 232 treated as 070180 treated as 221 205 treated as 045 233 treated as 084181 treated as 221 206 treated as 043 234 treated as 079182 treated as 221 207 treated as 045 235 treated as 100183 treated as 043 208 treated as 045 236 treated as 056184 treated as 043 209 treated as 045 237 treated as 102185 treated as 221 210 treated as 045 238 treated as 101186 treated as 221 211 treated as 043 239 treated as 110187 treated as 043 212 treated as 043 240 treated as 061188 treated as 043 213 treated as 043 242 treated as 061189 treated as 043 214 treated as 043 243 treated as 061190 treated as 043 215 treated as 043 244 treated as 040191 treated as 043 216 treated as 043 245 treated as 041192 treated as 043 217 treated as 043 247 treated as 126193 treated as 045 218 treated as 043 249 treated as 250194 treated as 045 219 treated as 221 251 treated as 118195 treated as 043 220 treated as 095 252 treated as 110196 treated as 045 222 treated as 221 254 treated as 221197 treated as 043 223 treated as 095198 treated as 221 224 treated as 097

  n’Importe quel caractère >0 pas dans la liste ci-dessus est traité comme lui-même, y compris <CR> et <LF>. Le moyen le plus simple d’inclure des caractères impairs comme <CR> Et <LF> est de les introduire dans une variable d’environnement et d’utiliser l’extension retardée dans l’argument de ligne de commande.,

  Limites de caractères pour les chaînes trouvées dans les fichiers spécifiés par /G:FILE et / F:FILE options
  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<CR>Et<LF> 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 d’un seul octet sont parfaitement inclus dans une chaîne.,

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

  cependant, la commande TYPE convertit UTF-16LE avec BOM en un seul jeu de caractères octet, donc 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 codes active seront convertis ? caractères.,

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

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

  Findstr casse les lignes immédiatement après chaque <LF>. La présence ou l’absence de <CR> n’a pas d’impact sur les sauts de ligne.

  recherche à travers les sauts de ligne
  comme prévu, le . métacaractère regex ne correspondra pas <CR> ou <LF>. Mais il est possible de rechercher à travers un saut de ligne en utilisant une chaîne de recherche en ligne de commande., À la fois le <CR> et <LF> caractères doivent être adaptées de manière explicite. Si une correspondance multiligne est trouvée, seule la 1ère ligne de la correspondance est imprimée. FINDSTR revient ensuite à la 2e ligne de la source et recommence la recherche – une sorte de fonctionnalité de type « regarder vers l’avenir ».

  Supposons TEXTE.,TXT a ces contenus (peut être de style Unix ou Windows)

  AAABAA

  alors ce script

  donne ces résultats

  1:A2:A5:A

  La recherche à travers les sauts de ligne en utilisant l’option /G:FILE est imprécise car la seule façon de faire correspondre <CR> ou <LF> est via une expression de plage de classe de caractères regex qui Sandwich les caractères EOL.,

  • matches <LF>, but it also matches <TAB> and <0x0B>

  • matches <CR>, but it also matches <0x0C> and !

  Note – the above are symbolic representations of the regex byte stream since I can’t graphically represent the characters.,

  suite de la réponse dans la partie 2 ci-dessous…