Quali sono le funzionalità e le limitazioni non documentate del comando Windows FINDSTR?

Prefazione
Molte delle informazioni contenute in questa risposta sono state raccolte sulla base di esperimenti eseguiti su una macchina Vista. Se non diversamente specificato, non ho confermato se le informazioni si applicano ad altre versioni di Windows.

FINDSTR output
La documentazione non si preoccupa mai di spiegare l’output di FINDSTR. Allude al fatto che le linee corrispondenti sono stampate, ma niente di più.,

Il formato di output della riga corrispondente è il seguente:

nomefile:lineNumber:lineOffset:text

dove

nomeFile: = Il nome del file contenente la riga corrispondente. Il nome del file non viene stampato se la richiesta è stata esplicitamente per un singolo file, o se la ricerca di input piped o input reindirizzato. Una volta stampato, il nome del file includerà sempre tutte le informazioni sul percorso fornite. Ulteriori informazioni sul percorso verranno aggiunte se viene utilizzata l’opzione/S. Il percorso stampato è sempre relativo al percorso fornito o relativo alla directory corrente se non fornito.,

Nota: il prefisso del nome file può essere evitato durante la ricerca di più file utilizzando i caratteri jolly non standard (e scarsamente documentati)< e>. Le regole esatte per come funzionano questi caratteri jolly possono essere trovate qui. Infine, puoi guardare questo esempio di come funzionano i caratteri jolly non standard con FINDSTR.

lineNumber: = Il numero di riga della riga corrispondente rappresentato come un valore decimale con 1 che rappresenta la 1a riga dell’input. Stampato solo se è specificata l’opzione/N.,

lineOffset: = L’offset del byte decimale dell’inizio della riga corrispondente, con 0 che rappresenta il 1 ° carattere della 1 ° riga. Stampato solo se è specificata l’opzione/O. Questo non è l’offset della corrispondenza all’interno della linea. È il numero di byte dall’inizio del file all’inizio della riga.

text = La rappresentazione binaria della riga corrispondente, inclusa qualsiasi<CR> e/o<LF>., Nulla viene lasciato fuori dall’output binario, in modo tale che questo esempio che corrisponde a tutte le linee produrrà una copia binaria esatta del file originale.

FINDSTR "^" FILE >FILE_COPY

L’opzione / A imposta solo il colore del nome file:, lineNumber: e lineOffset: output. Il testo della riga corrispondente viene sempre emesso con il colore corrente della console. L’opzione / A ha effetto solo quando l’output viene visualizzato direttamente sulla console. L’opzione / A non ha alcun effetto se l’output viene reindirizzato a un file o convogliato., Vedi la modifica 2018-08-18 nella risposta di Aacini per una descrizione del comportamento buggy quando l’output viene reindirizzato a CON.

La maggior parte dei caratteri di controllo e molti caratteri ASCII estesi vengono visualizzati come punti su XP
FINDSTR su XP visualizza la maggior parte dei caratteri di controllo non stampabili dalle linee corrispondenti come punti (punti) I seguenti caratteri di controllo sono eccezioni; vengono visualizzati come se stessi: 0x09 Tab, 0x0a LineFeed, 0x0b Tab Verticale, 0x0c Form Feed, 0X0D Carriage Return.

XP FINDSTR converte anche un certo numero di caratteri ASCII estesi in punti., I caratteri ASCII estesi che vengono visualizzati come punti su XP sono gli stessi che vengono trasformati quando forniti sulla riga di comando. Vedere la sezione” Limiti di caratteri per i parametri della riga di comando – Trasformazione ASCII estesa”, più avanti in questo post

I caratteri di controllo e l’ASCII esteso non vengono convertiti in punti su XP se l’output viene convogliato, reindirizzato a un file o all’interno di una clausola FOR IN ().

Vista e Windows 7 visualizzano sempre tutti i caratteri come se stessi, mai come punti.,

Codici di ritorno (ERRORLEVEL)

• 0 (successo)
  • La corrispondenza è stata trovata in almeno una riga di almeno un file.
• 1 (errore)
  • Nessuna corrispondenza è stata trovata in nessuna riga di qualsiasi file.,iv id=”b01f5d4aef”> /D: o /G:
  • File specificato da /F:file o /G:file non trovato
• 255 (errore)
  • Troppi espressione regolare la classe di caratteri termini
    vedere Regex classe di personaggio termine e BUG nella parte 2 di risposta

Fonte di dati per la ricerca (Aggiornato in base ai test con Windows 7)
Findstr possibile cercare i dati da una sola delle seguenti fonti:

• nomi di file specificati come argomenti e/o utilizzando i tag /F:file opzione.,

• stdin tramite reindirizzamentofindstr "searchString" <file

• flusso di dati da una pipetype file | findstr "searchString"

Gli argomenti / opzioni hanno la precedenza sul reindirizzamento, che ha la precedenza sui dati piped.

Gli argomenti del nome file e /F:file possono essere combinati. È possibile utilizzare più argomenti nome file. Se vengono specificate più opzioni/F:file, viene utilizzata solo l’ultima. Le wild card sono consentite negli argomenti del nome del file, ma non all’interno del file indicato da /F:file.,

Origine delle stringhe di ricerca (aggiornate in base ai test con Windows 7)
Le opzioni /G:file e /C:string possono essere combinate. È possibile specificare più opzioni/C:string. Se vengono specificate più opzioni/G:file, viene utilizzata solo l’ultima. Se si utilizza /G:file o /C:string, si presume che tutti gli argomenti non opzioni siano file da cercare., Se non viene utilizzato né /G:file né /C:string, il primo argomento non opzione viene trattato come un elenco delimitato da spazi di termini di ricerca.

I nomi dei file non devono essere citati all’interno del file quando si utilizza l’opzione/F:FILE.
I nomi dei file possono contenere spazi e altri caratteri speciali. La maggior parte dei comandi richiede che tali nomi di file siano citati. Ma l’opzione FINDSTR/F:files.txt richiede che i nomi dei file all’interno dei file.txt NON deve essere citato. Il file non verrà trovato se il nome è citato.

BUG-Breve 8.,3 nomi di file possono interrompere le opzioni/D e/S
Come con tutti i comandi di Windows, FINDSTR tenterà di abbinare sia il nome lungo che il nome breve 8.3 quando si cercano i file da cercare. Assumere la cartella corrente contiene i seguenti non vuota file:

b1.txtb.txt2c.txt

Il seguente comando che non riesca a trovare tutti e 3 i file:

findstr /m "^" *.txt

b.txt2 partite, perché il corrispondente nome breve B9F64~1.TXT partite., Ciò è coerente con il comportamento di tutti gli altri comandi di Windows.

Ma un bug con il /D e /S opzioni comporta i seguenti comandi per trovare solo b1.txt

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

Il bug impedisce b.txt2 trovato, così come tutti i nomi di file che è sorta dopo b.txt2 all’interno della stessa directory. Vengono trovati file aggiuntivi che vengono ordinati prima, come a.txt., File aggiuntivi che ordinano in seguito, comed.txt, vengono persi una volta attivato il bug.

Ogni directory ricercata viene trattata in modo indipendente. Ad esempio, l’opzione/S inizierebbe con successo la ricerca in una cartella secondaria dopo aver fallito nel trovare i file nel genitore, ma una volta che il bug causa la mancanza di un nome di file breve nel figlio, anche tutti i file successivi in quella cartella secondaria verrebbero persi.

I comandi funzionano senza errori se gli stessi nomi di file vengono creati su una macchina che ha la generazione di nomi NTFS 8.3 disabilitata., Ovviamente b.txt2 non sarebbe stato trovato, ma c.txt sarebbe stato trovato correttamente.

Non tutti i nomi brevi attivano il bug. Tutte le istanze di comportamento bugged che ho visto coinvolgono un’estensione più lunga di 3 caratteri con un nome 8.3 breve che inizia come un nome normale che non richiede un nome 8.3.

Il bug è stato confermato su XP, Vista e Windows 7.,

Caratteri non stampabili e l’opzione/P
L’opzione /Pfa sì che FINDSTR salti qualsiasi file contenente uno dei seguenti codici di byte decimali:
0-7, 14-25, 27-31.

In altre parole, l’opzione/P salta solo i file che contengono caratteri di controllo non stampabili. I caratteri di controllo sono codici inferiori o uguali a 31 (0x1F)., FINDSTR considera stampabili i seguenti caratteri di controllo:

 8 0x08 backspace 9 0x09 horizontal tab10 0x0A line feed11 0x0B vertical tab12 0x0C form feed13 0x0D carriage return26 0x1A substitute (end of text)

Tutti gli altri caratteri di controllo sono considerati non stampabili, la cui presenza fa sì che l’opzione/P salti il file.

L’input convogliato e reindirizzato può avere <CR><LF> aggiunto
Se l’input è convogliato e l’ultimo carattere del flusso non è <LF>, allora FINDSTR aggiungerà automaticamente <CR><LF> all’input. Questo è stato confermato su XP, Vista e Windows 7., (Pensavo che la pipe di Windows fosse responsabile della modifica dell’input, ma da allora ho scoperto che FINDSTR sta effettivamente facendo la modifica.)

Lo stesso vale per l’input reindirizzato su Vista. Se l’ultimo carattere di un file utilizzato come input reindirizzato non è <LF>, FINDSTR aggiungerà automaticamente <CR><LF> all’input. Tuttavia, XP e Windows 7 non alterano l’input reindirizzato.

FINDSTR si blocca su XP e Windows 7 se l’input reindirizzato non termina con<LF>
Questa è una brutta “funzionalità” su XP e Windows 7., Se l’ultimo carattere di un file utilizzato come input reindirizzato non termina con <LF>, FINDSTR si bloccherà indefinitamente una volta raggiunta la fine del file reindirizzato.

L’ultima riga di dati Piped può essere ignorata se è costituita da un singolo carattere
Se l’input viene convogliato e l’ultima riga è costituita da un singolo carattere che non è seguito da<LF>, FINDSTR ignora completamente l’ultima riga.,

Esempio – Il primo comando con un singolo carattere e nessun<LF> non riesce a corrispondere, ma il secondo comando con 2 caratteri funziona bene, così come il terzo comando che ha un carattere con fine a capo.

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

Segnalato da DosTips Pancia spugna utente al nuovo bug findstr. Confermato su XP, Windows 7 e Windows 8. Non ho ancora sentito parlare di Vista. (Non ho più Vista da testare).

Sintassi delle opzioni
Le lettere delle opzioni non sono case sensitive, quindi/i e/I sono equivalenti.,

Le opzioni possono essere precedute da / o Le opzioni possono essere concatenate dopo un singolo / o -. Tuttavia, l’elenco delle opzioni concatenate può contenere al massimo un’opzione multicharacter come OFF o F: e l’opzione multi-carattere deve essere l’ultima opzione nell’elenco.,

I seguenti sono tutti modi equivalenti di esprimere una distinzione tra maiuscole e minuscole regex di ricerca per ogni riga che contiene “ciao” e “arrivederci” in qualsiasi ordine,

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

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

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

Se una stringa di ricerca inizia con un / o - letterale, quindi il /C o /G opzione deve essere utilizzata. Grazie a Stephan per aver segnalato questo in un commento (dal momento che cancellato).,

Limiti di lunghezza della stringa di ricerca
In Vista la lunghezza massima consentita per una singola stringa di ricerca è di 511 byte. Se una stringa di ricerca supera 511, il risultato è un erroreFINDSTR: Search string too long. con ERRORLEVEL 2.

Quando si esegue una ricerca di espressioni regolari, la lunghezza massima della stringa di ricerca è 254. Un’espressione regolare con lunghezza compresa tra 255 e 511 genererà un erroreFINDSTR: Out of memory con ERRORLEVEL 2. Una lunghezza di espressione regolare>511 genera l’erroreFINDSTR: Search string too long..,

Su Windows XP la lunghezza della stringa di ricerca è apparentemente più breve. Errore Findstr: “Stringa di ricerca troppo lunga”: Come estrarre e abbinare la sottostringa nel ciclo “for”?Il limite di XP è di 127 byte per le ricerche letterali e regex.

Limiti di lunghezza linea
I file specificati come argomento della riga di comando o tramite l’opzione / F:FILE non hanno limiti di lunghezza linea noti. Le ricerche sono state eseguite con successo su un file da 128 MB che non conteneva un singolo <LF>.

I dati convogliati e l’input reindirizzato sono limitati a 8191 byte per riga., Questo limite è una “caratteristica” di FINDSTR. Non è inerente ai tubi o al reindirizzamento. FINDSTR utilizzando stdin reindirizzato o l’ingresso piped non corrisponderà mai a nessuna riga che è>=8k byte. Lines >= 8k genera un messaggio di errore su stderr, ma ERRORLEVEL è ancora 0 se la stringa di ricerca viene trovata in almeno una riga di almeno un file.

Tipo di ricerca predefinito: Letterale vs Espressione regolare
/C:"string" – Il valore predefinito è / L letterale. Combinando esplicitamente l’opzione /L con / C:”string” funziona certamente ma è ridondante.,

"string argument" – Il valore predefinito dipende dal contenuto della prima stringa di ricerca. (Ricorda che<lo spazio> viene utilizzato per delimitare le stringhe di ricerca.) Se la prima stringa di ricerca è un’espressione regolare valida che contiene almeno un meta-carattere non escape, tutte le stringhe di ricerca vengono trattate come espressioni regolari. Altrimenti tutte le stringhe di ricerca vengono trattate come letterali., Ad esempio, "51.4 200" verrà trattato come due espressioni regolari perché la prima stringa contiene un punto non escape, mentre "200 51.4" verrà trattato come due letterali perché la prima stringa non contiene alcun meta-carattere.

/G:file – Il valore predefinito dipende dal contenuto della prima riga non vuota nel file. Se la prima stringa di ricerca è un’espressione regolare valida che contiene almeno un meta-carattere non escape, tutte le stringhe di ricerca vengono trattate come espressioni regolari., Altrimenti tutte le stringhe di ricerca vengono trattate come letterali.

Raccomandazione – Specificare sempre esplicitamente/L opzione letterale o/R opzione di espressione regolare quando si utilizza"string argument" o/G:file.

La specifica di più stringhe di ricerca letterali può dare risultati inaffidabili

Il seguente semplice esempio di FINDSTR non riesce a trovare una corrispondenza, anche se dovrebbe.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

Questo bug è stato confermato su Windows Server 2003, Windows XP, Vista e Windows 7.,

Basato su esperimenti, FINDSTR potrebbe non riuscire se tutte le seguenti condizioni sono soddisfatte:

• La ricerca è l’utilizzo di più letterale stringhe di ricerca
• Le stringhe di ricerca sono di diverse lunghezze
• Una breve stringa di ricerca ha una certa quantità di sovrapposizione con una lunga stringa di ricerca
• La ricerca è case sensitive (n /I opzione)

In ogni caso di fallimento che ho visto, è sempre uno dei più brevi stringhe di ricerca che non funziona.

Per maggiori informazioni vedi Perché questo esempio di FINDSTR con più stringhe di ricerca letterali non trova una corrispondenza?,

Virgolette e backslahses all’interno degli argomenti della riga di comando
Nota – I commenti dell’utente MC ND riflettono le regole orribilmente complicate per questa sezione. Sono coinvolte 3 distinte fasi di analisi:

• Primo cmd.,exe possono richiedere alcuni preventivi di essere scappato, come ^” (in realtà nulla a che fare con FINDSTR)
• Avanti FINDSTR utilizza il pre 2008 MS C/C++ argomento parser, che ha delle regole speciali per ” e \
• Dopo l’argomento parser finiture, FINDSTR inoltre considera \ seguita da un carattere alfanumerico come letterale, ma \ seguita dalla non-alfa-numerico carattere come un carattere di escape

Il resto di questa sezione evidenziata non è corretta al 100%. Può servire come guida per molte situazioni, ma le regole di cui sopra sono necessarie per una comprensione totale.,

Escape Quote all’interno delle stringhe di ricerca della riga di comando
Le virgolette all’interno delle stringhe di ricerca della riga di comando devono essere sfuggite con backslash come\". Questo è vero sia per le stringhe di ricerca letterali che regex. Thisinformation è stato confermato su XP, Vista e Windows 7.

Nota: La citazione può anche avere bisogno di essere sfuggito per il CMD.Parser EXE, ma questo non ha nulla a che fare con FINDSTR., Ad esempio, per cercare una citazione singola è possibile utilizzare:

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

Escape Backslash all’interno delle stringhe di ricerca letterali della riga di comando
Backslash in una stringa di ricerca letterale può normalmente essere rappresentato come\ o come \\. Sono in genere equivalenti. (Potrebbero esserci casi insoliti in Vista in cui il backslash deve sempre essere sfuggito, ma non ho una macchina Vista da testare).

Ma ci sono alcuni casi speciali:

Durante la ricerca di backslash consecutivi, tutti tranne l’ultimo devono essere visualizzati., L’ultima barra rovesciata può facoltativamente essere sfuggita.

• \\ può essere codificata come \\\ o \\\\
• \\\ può essere codificata come \\\\\ o \\\\\\

la Ricerca di uno o più barre rovesciate prima un preventivo è bizzarro. Logicwould suggeriscono che la citazione deve essere sfuggito, e ciascuno dei leadingbackslashes avrebbe bisogno di essere sfuggito, ma questo non funziona!, Invece,ogni leader barre rovesciate deve essere il doppio di escape, e la quoteis sfuggito normalmente:

• \" deve essere codificato come \\\\\"
• \\" deve essere codificato come \\\\\\\\\"

Come notato in precedenza, uno o più sfuggito citazioni possono anche richiedere una fuga con ^ CMD parser

Le informazioni contenute in questa sezione è stata confermata su XP e Windows 7.,

Backslash all’interno della riga di comando regex stringhe di ricerca

• solo Vista: barra Rovesciata in una regex deve essere doppia sfuggito come \\\\ o altro singolo sfuggito all’interno di una classe di caratteri impostato come

• XP e Windows 7: La barra rovesciata in una espressione regolare può sempre essere rappresentato come . Normalmente può essere rappresentato come \\. Ma questo non funziona mai se il backslash precede una citazione con escape.,imitato citazione deve risultare bedouble sfuggito, o altro con codice

  • \" può essere codificata come \\\\\" o \"
  • \\" può essere codificata come \\\\\\\\\" o \" o \\\"

la Fuga Preventivo e barra Rovesciata all’interno di /G:FILE letterale stringhe di ricerca
Autonomo preventivi e barre rovesciate all’interno di un letterale stringa di ricerca è stato specificato un file /G:file non deve essere sfuggito, ma possono essere.,

" e \" sono equivalenti.

\ e \\ sono equivalenti.

Se l’intento è trovare \\, almeno la barra rovesciata iniziale deve essere sfuggita. Entrambi\\\ e\\\\ funzionano.

Se l’intento è trovare “, almeno la barra rovesciata iniziale deve essere sfuggita. Entrambi\\" e\\\" funzionano.,

Escape Quote e Backslash all’interno di / G:FILE regex search strings
Questo è l’unico caso in cui le sequenze di escape funzionano come previsto in base alla documentazione. La citazione non è un metacarattere regex, quindi non deve essere sfuggito (ma può essere). Backslash è un metacarattere regex, quindi deve essere sfuggito.

Limiti di caratteri per i parametri della riga di comando – Trasformazione ASCII estesa
Il carattere null (0x00) non può apparire in nessuna stringa sulla riga di comando. Qualsiasi altro carattere singolo byte può apparire nella stringa (0x01-0xFF)., Tuttavia, FINDSTR converte molti caratteri ASCII estesi che trova all’interno dei parametri della riga di comando in altri caratteri. Questo ha un impatto importante in due modi:

1. Molti caratteri ASCII estesi non corrisponderanno se usati come stringa di ricerca sulla riga di comando. Questa limitazione è la stessa per le ricerche letterali e regex. Se una stringa di ricerca deve contenere ASCII esteso, è necessario utilizzare l’opzione/G:FILE.

2. FINDSTR potrebbe non riuscire a trovare un file se il nome contiene caratteri ASCII estesi e il nome del file è specificato sulla riga di comando., Se un file da cercare contiene ASCII esteso nel nome, è necessario utilizzare l’opzione/F:FILE.

Ecco un elenco completo delle trasformazioni di caratteri ASCII estese che FINDSTR esegue sulle stringhe della riga di comando. Ogni carattere è rappresentato come il valore del codice byte decimale. Il primo codice rappresenta il carattere fornito sulla riga di comando e il secondo codice rappresenta il carattere in cui viene trasformato. Nota – questa lista è stata compilata su una macchina degli Stati Uniti. Non so quale impatto potrebbero avere altre lingue su questa lista.,

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

Qualsiasi carattere >0 non nell’elenco precedente viene trattato come se stesso, incluso <CR> e <LF>. Il modo più semplice per includere caratteri dispari come <CR> e <LF> è di farli entrare in una variabile di ambiente e utilizzare l’espansione ritardata all’interno dell’argomento della riga di comando.,

Limiti di caratteri per le stringhe trovate nei file specificati dalle opzioni /G:FILE e / F:FILE
Il carattere nul (0x00) può apparire nel file, ma funziona come il terminatore di stringa C. Tutti i caratteri dopo un carattere nul sono trattati come una stringa diversa come se fossero su un’altra riga.

I caratteri<CR> e<LF> vengono trattati come terminatori di riga che terminano una stringa e non sono inclusi nella stringa.

Tutti gli altri caratteri a byte singolo sono inclusi perfettamente all’interno di una stringa.,

Ricerca di file Unicode
FINDSTR non può cercare correttamente la maggior parte degli Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32) perché non può cercare byte nul e Unicode in genere contiene molti byte nul.

Tuttavia, il comando TYPE converte UTF-16LE con BOM in un set di caratteri a singolo byte, quindi un comando come il seguente funzionerà con UTF-16LE con BOM.

type unicode.txt|findstr "search"

Si noti che i punti di codice Unicode non supportati dalla pagina di codice attiva verranno convertiti in caratteri ?.,

È possibile cercare UTF-8 finché la stringa di ricerca contiene solo ASCII. Tuttavia, l’output della console di qualsiasi carattere UTF-8 multi-byte non sarà corretto. Ma se si reindirizza l’output a un file, il risultato verrà codificato correttamente UTF-8. Si noti che se il file UTF-8 contiene una distinta base, la distinta base verrà considerata come parte della prima riga, che potrebbe eliminare una ricerca che corrisponde all’inizio di una riga.

È possibile cercare caratteri UTF-8 multi-byte se si inserisce la stringa di ricerca in un file di ricerca codificato UTF-8 (senza BOM) e utilizzare l’opzione /G.,

Fine riga
FINDSTR interrompe le righe immediatamente dopo ogni<LF>. La presenza o l’assenza di<CR > non ha alcun impatto sulle interruzioni di riga.

Ricerca in interruzioni di riga
Come previsto, il . regex metacarattere non corrispondere <CR> o <LF>. Ma è possibile cercare attraverso un’interruzione di riga utilizzando una stringa di ricerca della riga di comando., Sia i caratteri<CR> che<LF> devono essere abbinati esplicitamente. Se viene trovata una corrispondenza su più righe, viene stampata solo la prima riga della corrispondenza. FINDSTR quindi raddoppia di nuovo alla 2a riga nella sorgente e ricomincia la ricerca – una sorta di funzione di tipo “guarda avanti”.

Assume TESTO.,TXT ha questi contenuti (potrebbe essere Unix o Windows style)

AAABAA

Quindi, questo script

dà questi risultati

1:A2:A5:A

Ricerca in interruzioni di riga utilizzando l’ /G:FILE opzione è imprecisa perché l’unico modo per abbinare <CR> o <LF> tramite regex carattere di classe gamma espressione che panini EOL caratteri.,

• 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.,

Risposta continuata nella parte 2 di seguito…