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

Question

Les Fenêtres de commande FINDSTR est très documenté. Il est très basique, aide en ligne de commande disponibles par le biais FINDSTR /?ou HELP FINDSTR, mais il est très insuffisante. Il y a un petit peu plus de documentation en ligne à l' http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx?mfr=true.

Il y a beaucoup de FINDSTR caractéristiques et des limites qui ne sont même pas fait allusion dans la documentation. Ils ne pouvaient être prévus sans connaissance préalable et/ou d'attention à l'expérimentation.

Donc la question est - Ce que sont les sans-papiers FINDSTR caractéristiques et les limites?

Le but de cette question est de fournir un référentiel de nombreuses fonctionnalités non documentées de sorte que:

A) les Développeurs peuvent tirer pleinement parti des possibilités qu'il offre.

B) les Développeurs ne perdent pas leur temps à se demander pourquoi quelque chose ne fonctionne pas quand il semble comme il se doit.

Assurez-vous de connaître la documentation existante avant de répondre. Si l'information est couverte par l'AIDE, alors il n'a pas sa place ici.

Ni est-ce un endroit pour montrer utilisations intéressantes de FINDSTR. Si une logique de personne pouvait prévoir le comportement d'un usage particulier des FINDSTR basée sur la documentation, alors il n'a pas sa place ici.

Dans le même esprit, si une logique de personne pouvait prévoir le comportement d'un usage particulier fondé sur les renseignements contenus dans les réponses existantes, puis de nouveau, il n'a pas sa place ici.

Answer 1

Réponse suite à partir de ci-dessus - j'ai couru dans les 30 000 caractères limite de réponse :-(

Regex classe de caractères limite de durée et de BOGUE
Non seulement est FINDSTR limitée à un maximum de 15 caractères termes de classes à l'intérieur d'une regex, il ne parvient pas à traiter correctement une tentative de dépasser la limite. À l'aide de 16 ou plus d'une classe de personnage termes de résultats interactif des Fenêtres pop-up indiquant "Chaîne de recherche (QGREP) a rencontré un problème et doit fermer. Nous sommes désolés pour la gêne occasionnée." Le texte du message varie légèrement selon la version de Windows. Voici un exemple d'un FINDSTR qui ne manquera pas de:

echo 01234567890123456|findstr [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]

Ce bug a été signalé par DosTips utilisateur Judago ici. Il a été confirmé sur XP, Vista et Windows 7.

Regex recherche échouer (et peut se bloquer indéfiniment) si elles ont code octet 0xFF (décimal 255)
Tout regex de recherche qui inclut du code octet 0xFF (décimal 255) échouera. Il échoue si le code octet 0xFF est inclus directement, ou si elle est implicitement inclus dans une classe de caractère gamme. Rappelez-vous que FINDSTR classe de personnage plages de ne pas assembler des caractères basé sur le code d'octets de la valeur. Le caractère <0xFF> apparaît relativement tôt dans la séquence de classement entre l' <space> et <tab> caractères. Donc n'importe quel caractère de classe de la gamme qui comprend à la fois <space> et <tab> échouent.

Le comportement exact change légèrement selon la version de Windows. Windows 7 se bloque indéfiniment si 0xFF est inclus. XP ne se bloque pas, mais il ne parvient pas toujours à trouver une correspondance, et, occasionnellement, imprime le message d'erreur suivant: "Le processus a tenté d'écrire sur un inexistant pipe."

Je n'ai plus accès à une machine Vista, donc je n'ai pas pu tester sur Vista.

Regex bug: . et [^anySet] peut correspondre à Fin-De-Fichier
La regex . méta-caractère ne doit correspondre à n'importe quel caractère autre que <CR> ou <LF>. Il y a un bug qui lui permet de correspondre à la Fin-De-Fichier si la dernière ligne du fichier n'est pas résilié par l' <CR> ou <LF>. Cependant, l' . correspond pas à un fichier vide.

Par exemple, un fichier nommé "test.txt" contenant une seule ligne de x, sans résiliation <CR> ou <LF>, sera de faire correspondre les éléments suivants:

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

Ce bogue a été confirmé sur XP et Win7.

Cela semble être vrai pour les jeux de caractères. Quelque chose comme [^abc] correspondra à la Fin-De-Fichier. Positif de jeux de caractères comme [abc] semblent bien fonctionner. J'ai uniquement testé sur Win7.

Answer 2

findstr bloque parfois de manière inattendue lors de la recherche des fichiers volumineux.

Je n'ai pas confirmé les conditions exactes ou à la limite des tailles. Je soupçonne tout fichier de plus de 2 go peut être à risque.

J'ai eu des expériences avec ce, donc il est plus que juste la taille du fichier. Cela ressemble, il peut être une variation sur FINDSTR se bloque sur XP et Windows 7 si redirigé entrée ne prend pas fin avec LF, mais comme l'a démontré ce problème se manifeste lorsque l'entrée est pas redirigé.

La ligne de commande suivante session (Windows 7) montre comment findstr peut se bloquer lors de la recherche d'un fichier de 3 go.

C:\Data\Temp\2014-04>echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890> T100B.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,10) do @type T100B.txt >> T1KB.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1KB.txt >> T1MB.txt

C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1MB.txt >> T1GB.txt

C:\Data\Temp\2014-04>echo find this line>> T1GB.txt

C:\Data\Temp\2014-04>copy T1GB.txt + T1GB.txt + T1GB.txt T3GB.txt
T1GB.txt
T1GB.txt
T1GB.txt
        1 file(s) copied.

C:\Data\Temp\2014-04>dir
 Volume in drive C has no label.
 Volume Serial Number is D2B2-FFDF

 Directory of C:\Data\Temp\2014-04

2014/04/08  04:28 PM    <DIR>          .
2014/04/08  04:28 PM    <DIR>          ..
2014/04/08  04:22 PM               102 T100B.txt
2014/04/08  04:28 PM     1 020 000 016 T1GB.txt
2014/04/08  04:23 PM             1 020 T1KB.txt
2014/04/08  04:23 PM         1 020 000 T1MB.txt
2014/04/08  04:29 PM     3 060 000 049 T3GB.txt
               5 File(s)  4 081 021 187 bytes
               2 Dir(s)  51 881 050 112 bytes free
C:\Data\Temp\2014-04>rem Findstr on the 1GB file does not hang

C:\Data\Temp\2014-04>findstr "this" T1GB.txt
find this line

C:\Data\Temp\2014-04>rem On the 3GB file, findstr hangs and must be aborted... even though it clearly reaches end of file

C:\Data\Temp\2014-04>findstr "this" T3GB.txt
find this line
find this line
find this line
^C
C:\Data\Temp\2014-04>

Remarque, j'ai vérifié dans un éditeur hexadécimal que toutes les lignes sont interrompues par CRLF. La seule anomalie est que le fichier se termine par 0x1A en raison de la façon dont copy travaux. À noter toutefois, que cette anomalie n'est pas une cause d'un problème sur les "petits" fichiers.

Avec des tests supplémentaires me l'ont confirmé les éléments suivants:

• À l'aide de copy avec l' /b option pour les fichiers binaires empêche l'ajout de l' 0x1A caractère, et findstr ne se bloque pas sur les 3 go de fichiers.
• La résiliation de l'3 go de fichier avec un autre personnage provoque aussi l' findstr pour les accrocher.
• L' 0x1A caractère ne cause pas de problèmes sur un "petit" fichier. (De même pour les autres caractères de fin.)
• L'ajout d' CRLF après 0x1A résout le problème. (LF par lui-même serait probablement suffisant.)
• À l'aide de type à la pipe le fichier en findstr fonctionne sans accrocher. (Cela peut être dû à un effet secondaire de type ou | que des inserts supplémentaires à la Fin De la Ligne.)
• Utilisation redirigé entrée < provoque également findstr pour les accrocher. Mais c'est prévu; comme expliqué dans dbenham post: "redirection d'entrée doit se terminer en LF".