Windows FINDSTR komutunun belgelenmemiş özellikleri ve sınırlamaları nelerdir?

Windows FINDSTR komutu korkunç bir şekilde belgelenmiştir. Çok basit bir komut satırı yardımı var FINDSTR /?, ya da HELP FINDSTR, ama bu çok yetersiz. Https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr adresinde çevrimiçi olarak daha fazla dokümantasyon var .

Belgelerde ima edilmeyen birçok FINDSTR özelliği ve sınırlaması vardır. Ayrıca önceden bilgi ve / veya dikkatli deneyler yapılmadan da beklenemezler.

Yani soru şu: Belgesiz FINDSTR özellikleri ve sınırlamaları nelerdir?

Bu sorunun amacı, belgelenmemiş birçok özelliğin tek durak deposunu sağlamaktır, böylece:

A) Geliştiriciler orada bulunan özelliklerden tam olarak yararlanabilirler.

B) Geliştiriciler, bir şeyin olması gerektiği gibi neden çalışmadığını merak ederek zamanlarını boşa harcamazlar.

Lütfen yanıt vermeden önce mevcut belgeleri bildiğinizden emin olun. Bilgiler YARDIM kapsamındaysa, o zaman buraya ait değildir.

Burası FINDSTR'ın ilginç kullanımlarını göstermek için de bir yer değil. Mantıksal bir kişi, FINDSTR'ın belirli bir kullanımının belgelere dayalı davranışını tahmin edebiliyorsa, o zaman buraya ait değildir.

Aynı satırlar boyunca, mantıklı bir kişi mevcut herhangi bir cevapta yer alan bilgilere dayanarak belirli bir kullanımın davranışını tahmin edebiliyorsa, yine buraya ait değildir.

Önsöz Bu yanıttaki bilgilerin
çoğu, bir Vista makinesinde yapılan deneylere dayanarak toplanmıştır. Aksi açıkça belirtilmedikçe, bilgilerin diğer Windows sürümleri için geçerli olup olmadığını onaylamadım.

FINDSTR çıktısı
Doküman asla FINDSTR çıktısını açıklamaktan rahatsız olmaz. Eşleşen çizgilerin basıldığı gerçeğini ifade eder, ancak başka bir şey değildir.

Eşleşen hat çıktısının biçimi aşağıdaki gibidir:

Dosya adı: LineNumber: lineOffset: Metin

nerede

fileName: = Eşleşen satırı içeren dosyanın adı. İstek açıkça tek bir dosya içinse veya borulu giriş veya yeniden yönlendirilmiş giriş aranıyorsa dosya adı yazdırılmaz. Basıldığında, fileName her zaman sağlanan yol bilgilerini içerir. /SSeçenek kullanılırsaek yol bilgileri eklenir. Yazdırılan yol her zaman sağlanan yola göredir veya sağlanmamışsa geçerli dizine göredir.

Not - kullanarak birden çok dosya ararken dosya öneki önlenebilir standart dışı (ve kötü belgelenmiş) joker < ve >. Bu joker karakterlerin nasıl çalıştığına ilişkin kesin kuralları burada bulabilirsiniz . Son olarak, standart olmayan joker karakterlerin FINDSTR ile nasıl çalıştığına dair bu örneğe bakabilirsiniz .

lineNumber: = Eşleşen satırın ondalık değer olarak temsil edilen satır numarası, 1 girişin 1. satırını temsil eder. Yalnızca/Nseçenek belirtilirseyazdırılır.

lineOffset: = Eşleme satırının başlangıcındaki ondalık bayt uzaklığı, 0 1. satırın 1. karakterini temsil eder. Yalnızca/Oseçenek belirtilirseyazdırılır. Bu,çizgideki eşleşmenin ofseti değildir . Dosyanın başından satırın başına kadar olan bayt sayısıdır.

text = Herhangi bir <CR> ve / veya <LF> dahil olmak üzere eşleşen satırın ikili gösterimi. İkili çıktıda hiçbir şey kalmaz, böylece tüm satırlarla eşleşen bu örnek orijinal dosyanın tam bir ikili kopyasını oluşturur.

FINDSTR "^" FILE >FILE_COPY

/ A seçeneği yalnızca fileName :, lineNumber: ve lineOffset: output'un rengini ayarlar. Eşleşen satırın metni her zaman geçerli konsol rengiyle çıkarılır. / A seçeneği yalnızca çıktı doğrudan konsola görüntülendiğinde etkili olur. Çıktı bir dosyaya yönlendirilirse veya iletilirse, / A seçeneğinin bir etkisi yoktur. Çıktı CON'a yönlendirildiğinde hata ayıklama davranışının açıklaması için Aacini'nin cevabındaki 2018-08-18 düzenlemesine bakın .

Çoğu kontrol karakteri ve birçok genişletilmiş ASCII karakteri XP'de noktalar olarak görüntülenir XP'de
FINDSTR, yazdırılamayan kontrol karakterlerinin çoğunu, eşleşen satırlardan ekranda noktalar (nokta) olarak görüntüler. Aşağıdaki kontrol karakterleri istisnadır; kendileri gibi görünürler: 0x09 Sekmesi, 0x0A LineFeed, 0x0B Dikey Sekmesi, 0x0C Form Beslemesi, 0x0D Satır Başı.

XP FINDSTR ayrıca bir dizi genişletilmiş ASCII karakterini noktalara dönüştürür. XP'de nokta olarak görüntülenen genişletilmiş ASCII karakterleri, komut satırında sağlandığında dönüştürülen karakterlerle aynıdır. Bu yazının ilerisindeki "Komut satırı parametreleri için karakter sınırları - Genişletilmiş ASCII dönüşümü" bölümüne bakın.

Çıktı pipetlenirse, bir dosyaya yeniden yönlendirilirse veya bir FOR IN () yantümcesi içinde ise denetim karakterleri ve genişletilmiş ASCII, XP'deki noktalara dönüştürülmez.

Vista ve Windows 7 her zaman tüm karakterleri kendileri gibi gösterir, asla nokta olarak göstermez.

Dönüş Kodları (ERRORLEVEL)

• 0 (başarı)
  • Eşleşme, en az bir dosyanın en az bir satırında bulundu.
• 1 (hata)
  • Hiçbir dosyanın hiçbir satırında eşleşme bulunamadı.
  • /A:xxSeçenek tarafından geçersiz renk belirtildi
• 2 (hata)
  • Uyumsuz seçenekler /Lve /Rher ikisi de belirtildi
  • Eksik argüman sonra /A:, /F:, /C:, /D:, veya/G:
  • Tarafından belirtilen /F:fileveya /G:filebulunamadı dosya
• 255 (hata)
  • Çok fazla normal ifade karakter sınıfı terimi
    bkz . Yanıtın 2. bölümünde Regex karakter sınıfı terim sınırı ve HATA

Aranacak verilerin kaynağı ( Windows 7 ile yapılan testlere göre güncellenmiştir)
Findstr, aşağıdaki kaynaklardan yalnızca birinden veri arayabilir:

• argüman olarak belirtilen ve / veya /F:fileseçeneği kullanan dosya adları .

• yönlendirme yoluyla stdin findstr "searchString" <file

• borudan veri akışı type file | findstr "searchString"

Bağımsız değişkenler / seçenekler, yönlendirilen verilere göre yeniden yönlendirmeye göre önceliklidir.

Dosya adı bağımsız değişkenleri ve /F:filebirleştirilebilir. Birden çok dosya adı bağımsız değişkeni kullanılabilir. Birden fazla /F:fileseçenek belirtilirse, yalnızca son seçenek kullanılır. Dosya adı bağımsız değişkenlerinde joker karakterlere izin verilir, ancak işaret ettiği dosyada izin verilmez /F:file.

Arama dizeleri Kaynak (Windows 7 ile testlere dayanarak Updated) ve seçenekler birleştirilebilir. Birden fazla seçenek belirtilebilir. Birden fazla seçenek belirtilirse, yalnızca son seçenek kullanılır. Ya da kullanılırsa, seçenek olmayan tüm bağımsız değişkenlerin aranacak dosyalar olduğu varsayılır. Ne kullanılmaz ne de kullanılırsa, ilk seçenek olmayan argüman, boşlukla sınırlandırılmış arama terimleri listesi olarak kabul edilir.
/G:file/C:string/C:string/G:file/G:file/C:string/G:file/C:string

Bu /F:FILEseçenek kullanılırken dosya adları dosya içinde belirtilmemelidir .
Dosya adları boşluklar ve diğer özel karakterler içerebilir. Çoğu komut bu tür dosya adlarının alıntılanmasını gerektirir. Ancak FINDSTR /F:files.txtseçeneği, files.txt içindeki dosya adlarının tırnak içine alınmamasını gerektirir. Ad belirtilirse dosya bulunmaz.

HATA - Kısa 8.3 dosya adları /Dve /Sseçenekleri kırabilir
Tüm Windows komutlarında olduğu gibi, FINDSTR aranacak dosyaları ararken hem uzun adı hem de kısa 8.3 adını eşleştirmeye çalışır. Geçerli klasörün aşağıdaki boş olmayan dosyaları içerdiğini varsayın:

b1.txt
b.txt2
c.txt

Aşağıdaki komut 3 dosyanın tümünü başarıyla bulur:

findstr /m "^" *.txt

b.txt2karşılık gelen kısa ad B9F64~1.TXTeşleştiğinden eşleşir. Bu, diğer tüm Windows komutlarının davranışlarıyla tutarlıdır.

Ancak /Dve /Sseçenekleriyle ilgili bir hata , aşağıdaki komutların yalnızcab1.txt

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

Hata , aynı dizinde b.txt2sıralanan tüm dosya adlarının yanı sıra bulunmasını engeller b.txt2. Daha önce sıralama gibi ek dosyalar a.txtbulunur. Daha sonra d.txtsıralanan ek dosyalar , hata tetiklendikten sonra kaçırılır.

Aranan her dizin bağımsız olarak ele alınır. Örneğin, /Sseçenek üst dosyadaki dosyaları bulamadan sonra bir alt klasörde başarıyla aramaya başlar, ancak hata alt öğede kısa bir dosya adının kaçırılmasına neden olduğunda, o alt klasördeki sonraki tüm dosyalar da kaçırılır .

NTFS 8.3 ad oluşturma devre dışı bırakılmış bir makinede aynı dosya adları oluşturulursa, komutlar hatasız çalışır. Tabii ki b.txt2bulunamadı, ama c.txtdüzgün bulunacaktı.

Kısa adların tümü hatayı tetiklemez. Gördüğüm tüm hata davranışları, 8.3 adı gerektirmeyen normal bir adla aynı başlayan kısa bir 8.3 adıyla 3 karakterden daha uzun bir uzantı içerir.

Hata XP, Vista ve Windows 7'de onaylandı.

Yazdırılamayan karakterler ve /Pseçenek
Bu /Pseçenek, FINDSTR'un aşağıdaki ondalık bayt kodlarından herhangi birini içeren herhangi bir dosyayı atlamasına neden olur:
0-7, 14-25, 27-31.

Başka bir deyişle, /Pseçenek yalnızca yazdırılamayan kontrol karakterleri içeren dosyaları atlayacaktır. Kontrol karakterleri 31 (0x1F) veya daha küçük kodlardır. FINDSTR aşağıdaki kontrol karakterlerini yazdırılabilir olarak kabul eder:

 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)

Diğer tüm kontrol karakterleri yazdırılamaz olarak kabul edilir, bu da varlığı /Pdosyayı atlama seçeneğine neden olur .

Borulu ve<CR><LF>
Yeniden Yönlendirilmiş giriş eklenmiş olabilir Giriş içeri aktarılırsa ve akışın son karakteri değilse <LF>, FINDSTR otomatik olarak <CR><LF>girdiye eklenir . Bu, XP, Vista ve Windows 7'de onaylandı. (Windows borusunun girdiyi değiştirmekle sorumlu olduğunu düşünürdüm, ancak o zamandan beri FINDSTR'ın aslında değişikliği yaptığını keşfettim.)

Aynı şey Vista'daki yeniden yönlendirilmiş giriş için de geçerlidir. Yeniden yönlendirilmiş giriş olarak kullanılan bir dosyanın son karakteri değilse <LF>, FINDSTR otomatik olarak <CR><LF>girişe eklenir . Ancak, XP ve Windows 7 yeniden yönlendirilen girişi değiştirmez.

Yeniden yönlendirilen giriş ile bitmezse FINDSTR XP ve Windows 7'de kilitleniyor Bu, XP ve Windows 7'de<LF>
kötü bir "özellik" ise, Yeniden yönlendirilmiş giriş olarak kullanılan bir dosyanın son karakteri <LF>bitmezse, FINDSTR süresiz olarak kilitlenir yeniden yönlendirilen dosyanın sonuna ulaşır.

Borulu verilerin son satırı, tek bir karakterden oluşuyorsa yok sayılabilir
. Giriş <LF>içeri aktarılırsa ve son satırı takip edilmeyen tek bir karakterden oluşuyorsa, FINDSTR son satırı tamamen yok sayar.

Örnek - Tek bir karaktere sahip olan ve hiçbir <LF>karakter içermeyen ilk komut eşleşemez, ancak 2 karakterli ikinci komut, son satırsonu karakteri olan bir karaktere sahip üçüncü komutta olduğu gibi iyi çalışır.

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

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

> echo x| findstr "^"
x

DosTips kullanıcısı Sünger Göbek tarafından yeni findstr hatasıyla bildirildi . XP, Windows 7 ve Windows 8'de onaylandı. Vista hakkında henüz bir şey duymadım. (Artık test edeceğim Vista yok).

Seçenek sözdizimi
Seçeneklerin herhangi biri ile öneki olabilir /veya -Seçenekler tek bir /veya sonra birleştirilebilir -. Ancak, birleştirilmiş seçenek listesi, OFF veya F: gibi en fazla bir çok karakterli seçenek içerebilir ve çok karakterli seçenek listedeki son seçenek olmalıdır.

Aşağıdakilerin tümü, herhangi bir sırada hem "merhaba" hem de "güle güle" içeren herhangi bir satır için büyük / küçük harfe duyarlı olmayan normal ifade aramasını ifade etmenin eşdeğer yollarıdır.

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

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

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

Arama Dizesi uzunluk sınırları
Vista'da tek bir arama dizesi için izin verilen maksimum uzunluk 511 bayttır. Herhangi bir arama dizesi 511'i aşarsa, sonuç FINDSTR: Search string too long.ERRORLEVEL 2 ile ilgili bir hatadır.

Normal bir ifade araması yaparken, maksimum arama dizesi uzunluğu 254'tür. 255 ile 511 arasında bir FINDSTR: Out of memoryuzunluğa sahip normal bir ifade, ERRORLEVEL 2 ile ilgili bir hatayla sonuçlanacaktır FINDSTR: Search string too long..

Windows XP'de arama dizesi uzunluğu açıkça daha kısadır. Findstr hatası: "Arama dizesi çok uzun": "for" döngüsünde alt dize nasıl ayıklanır ve eşleştirilir? XP sınırı, hem değişmez hem de normal ifade aramaları için 127 bayttır.

Satır Uzunluğu sınırları
Komut satırı bağımsız değişkeni olarak veya / F: FILE seçeneği ile belirtilen dosyaların bilinen bir satır uzunluğu sınırı yoktur. Aramalar tek bir <LF> içermeyen 128 MB'lık bir dosyada başarıyla gerçekleştirildi.

Borulu veriler ve Yönlendirilen giriş hat başına 8191 bayt ile sınırlıdır. Bu sınır FINDSTR'ın bir "özelliğidir". Borular veya yönlendirme için doğal değildir. Yeniden yönlendirilmiş standart veya borulu giriş kullanan FINDSTR, hiçbir zaman> = 8k bayt olan herhangi bir satırla eşleşmez. Çizgiler> = 8k stderr'a bir hata mesajı oluşturur, ancak arama dizesi en az bir dosyanın en az bir satırında bulunursa ERRORLEVEL hala 0'dır.

Varsayılan arama türü: Değişmez ve Normal İfade
/C:"string" - Varsayılan / L değişmez değeridir. / L seçeneğini / C: "string" ile açıkça birleştirmek kesinlikle işe yarar ama gereksizdir.

"string argument"- Varsayılan, ilk arama dizesinin içeriğine bağlıdır. (<space> öğesinin arama dizelerini sınırlamak için kullanıldığını unutmayın.) İlk arama dizesi, en az bir çıkış karakteri bulunmayan meta karakter içeren geçerli bir normal ifadeyse, tüm arama dizeleri normal ifadeler olarak kabul edilir. Aksi takdirde, tüm arama dizeleri değişmez olarak kabul edilir. Örneğin "51.4 200", ilk dize kaçan bir nokta içerdiğinden iki normal ifade "200 51.4"olarak ele alınırken, ilk dize herhangi bir meta karakter içermediğinden iki değişmez olarak ele alınacaktır.

/G:file- Varsayılan, dosyadaki ilk boş olmayan satırın içeriğine bağlıdır. İlk arama dizesi, en az bir çıkış karakteri bulunmayan meta karakter içeren geçerli bir normal ifadeyse, tüm arama dizeleri normal ifadeler olarak kabul edilir. Aksi takdirde, tüm arama dizeleri değişmez olarak kabul edilir.

Öneri - Her zaman açıkça belirtmek /Lliteral seçeneği veya /Rkullanırken düzenli ifade seçeneğini "string argument"veya /G:file.

HATA - Birden çok değişmez arama dizesi belirtmek güvenilir olmayan sonuçlar verebilir

Aşağıdaki basit FINDSTR örneği, bir eşleşme bulamamasına rağmen başarısız oluyor.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

Bu hata Windows Server 2003, Windows XP, Vista ve Windows 7'de onaylanmıştır.

Deneylere dayanarak, aşağıdaki koşulların tümü yerine getirilirse FINDSTR başarısız olabilir:

• Arama birden çok değişmez arama dizesi kullanıyor
• Arama dizeleri farklı uzunluklarda
• Kısa bir arama dizesinde, daha uzun bir arama dizesiyle bir miktar çakışma vardır
• Arama büyük / küçük harfe duyarlıdır ( /Iseçenek yok )

Gördüğüm her hatada, her zaman başarısız olan kısa arama dizelerinden biridir.

Daha fazla bilgi için bkz. Birden çok değişmez arama dizesine sahip bu FINDSTR örneği neden bir eşleşme bulamıyor?

Komut satırı bağımsız değişkenleri içindeki tırnak işaretleri ve ters hatalar
Not - Kullanıcı MC ND'nin yorumları, bu bölüm için korkunç derecede karmaşık kuralları yansıtır. 3 ayrı ayrıştırma aşaması söz konusudur:

• İlk cmd.exe bazı tırnakların ^ "olarak kaçmasını gerektirebilir (FINDSTR ile gerçekten ilgisi yoktur)
• Sonraki FINDSTR, "ve \ için özel kurallara sahip olan 2008 öncesi MS C / C ++ bağımsız değişken ayrıştırıcısını kullanır
• Bağımsız değişken ayrıştırıcısı bittikten sonra, FINDSTR \ 'karakterini ek olarak \ ve ardından alfa-sayısal karakteri değişmez, \ \ ve ardından alfa-sayısal olmayan karakteri çıkış karakteri olarak ele alır

Vurgulanan bu bölümün geri kalanı% 100 doğru değil. Birçok durum için bir rehber görevi görebilir, ancak toplam kurallar için yukarıdaki kurallar gereklidir.

Komut satırı arama dizeleri içinde Alıntı Yapma Komut satırı arama dizeleri
içindeki alıntılar ters eğik çizgi ile kaçmalıdır \". Bu hem değişmez hem de normal ifade arama dizeleri için geçerlidir. Bu bilgiler XP, Vista ve Windows 7'de onaylanmıştır.

Not: Alıntı CMD.EXE ayrıştırıcı için de kaçması gerekebilir, ancak bunun FINDSTR ile ilgisi yoktur. Örneğin, tek bir fiyat teklifi aramak için şunları kullanabilirsiniz:

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

Komut satırı değişmez arama dizeleri içinde
Ters Eğik Çizgi'den kaçınma Değişmez arama dizesindeki ters eğik çizgi normal olarak \veya olarak temsil edilebilir \\. Bunlar tipik olarak eşdeğerdir. (Vista'da ters eğik çizginin her zaman kaçması gereken olağandışı durumlar olabilir, ancak artık test etmek için bir Vista makinem yok) .

Ancak bazı özel durumlar var:

Ardışık ters eğik ararken, tüm ama son zorunluluk öncelenmelidir. Son ters eğik çizgi isteğe bağlı olarak kaçabilir.

• \\olarak kodlanabilir \\\ya da\\\\
• \\\olarak kodlanabilir \\\\\ya da\\\\\\

Bir tekliften önce bir veya daha fazla ters eğik çizgi aramak tuhaftır. Mantık, alıntıdan kaçılması gerektiğini ve önde gelen ters eğik çizgilerin her birinin kaçması gerektiğini önerecektir, ancak bu işe yaramaz! Bunun yerine, önde gelen ters eğik çizgilerin her biri iki kez kaçmalı ve teklif normal şekilde kaçmalıdır:

• \" olarak kodlanmalıdır \\\\\"
• \\" olarak kodlanmalıdır \\\\\\\\\"

Daha önce belirtildiği gibi, bir veya daha fazla kaçan tırnak ^CMD ayrıştırıcısı için kaçmayı da gerektirebilir

Bu bölümdeki bilgiler XP ve Windows 7'de onaylanmıştır.

Komut satırı normal ifade arama dizelerinde Ters Eğik Çizgi'den kaçma

• Yalnızca Vista: Normal ifadedeki ters eğik çizgi, ya çift \\\\karakterden kaçmalı ya da başka bir karakter sınıfı kümesinden tek çıkış karakterli olmalıdır [\\]

• XP ve Windows 7: Bir normal ifadedeki ters eğik çizgi her zaman olarak temsil edilebilir [\\]. Normalde olarak temsil edilebilir \\. Ancak, ters eğik çizgi kaçan bir alıntıdan önce gelirse bu asla işe yaramaz.

  Kaçan bir alıntıdan önce bir veya daha fazla ters eğik çizgi çift kaçış veya başka bir şekilde kodlanmış olmalıdır [\\]

  • \"gibi kodlanmış olabilir \\\\\"ya da[\\]\"
  • \\"gibi kodlanmış olabilir \\\\\\\\\"ya da [\\][\\]\"ya da\\[\\]\"

/ G: FILE değişmez arama dizeleri içinde Alıntı ve Ters Eğik Çizgi'ten kaçınma / G:
dosyası ile belirtilen değişmez bir arama dizesi dosyasındaki bağımsız tırnak işaretleri ve ters eğik çizgilerden kaçınılması gerekmez, ancak olabilirler.

"ve \"eşdeğerdir.

\ve \\eşdeğerdir.

Amaç \\ bulmaksa, en azından önde gelen ters eğik çizgiden kaçılmalıdır. Hem \\\ve \\\\çalışması.

Niyet "\ bulmak ise, o zaman en azından baştaki ters şekilde çıkmalıdır. Hem \\"ve \\\"işi.

/ G: FILE regex arama dizeleri içinde Alıntı ve Ters Eğik Çizgi'ten kaçış
Bu, kaçış dizilerinin belgelere dayanarak beklendiği gibi çalıştığı tek durumdur. Alıntı bir regex metakarakter değildir, bu yüzden kaçmasına gerek yoktur (ama olabilir). Ters eğik çizgi normal ifade metakarakteridir, bu yüzden kaçmak gerekir.

Komut satırı parametreleri için karakter sınırları - Genişletilmiş ASCII dönüşümü
Boş karakter (0x00), komut satırındaki hiçbir dizede görünemez. Dizede başka herhangi bir tek bayt karakteri görünebilir (0x01 - 0xFF). Ancak FINDSTR, komut satırı parametreleri içinde bulduğu birçok genişletilmiş ASCII karakterini diğer karakterlere dönüştürür. Bunun iki şekilde büyük bir etkisi vardır:

1) Komut satırında arama dizesi olarak kullanılırsa, birçok genişletilmiş ASCII karakteri eşleşmez. Bu sınırlama, değişmez ve normal ifade aramaları için aynıdır. Bir arama dizesi genişletilmiş ASCII içermesi gerekiyorsa, /G:FILEbunun yerine seçenek kullanılmalıdır.

2) Ad genişletilmiş ASCII karakterleri içeriyorsa ve dosya adı komut satırında belirtilmişse, FINDSTR dosya bulamayabilir. Aranacak bir dosya adında genişletilmiş ASCII içeriyorsa, /F:FILEbunun yerine seçenek kullanılmalıdır.

FINDSTR'ın komut satırı dizelerinde gerçekleştirdiği genişletilmiş ASCII karakter dönüşümlerinin tam listesi. Her karakter ondalık bayt kod değeri olarak temsil edilir. İlk kod, komut satırında sağlanan karakteri ve ikinci kod dönüştürüldüğü karakteri temsil eder. Not - bu liste bir ABD makinesinde derlenmiştir. Diğer dillerin bu listede ne gibi etkileri olabileceğini bilmiyorum.

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

Yukarıdaki listede olmayan> 0 karakteri <CR>ve < dahil olmak üzere kendisi olarak kabul edilir LF>. En kolay yolu gibi tuhaf karakterleri içerecek şekilde <CR>ve <LF>çevre değişkene onları almak ve komut satırı argümanı içinde gecikmeli genişleme kullanmaktır.

/ G: FILE ve / F: FILE seçenekleri tarafından belirtilen dosyalarda bulunan dizeler için karakter sınırları
Nul (0x00) karakteri dosyada görünebilir, ancak C dizesi sonlandırıcısı gibi çalışır. Bir boş karakterden sonraki tüm karakterler, başka bir satırdaymış gibi farklı bir dize olarak ele alınır.

<CR>Ve <LF>karakterler bir dize sonlandırmak ve dizede yer almayan satır sonlandırıcı olarak kabul edilir.

Diğer tüm tek bayt karakterler bir dizeye mükemmel şekilde dahil edilir.

Unicode dosyalarında
arama FINDSTR, nul baytları arayamayacağından ve Unicode genellikle çok sayıda nul bayt içerdiğinden çoğu Unicode'u (UTF-16, UTF-16LE, UTF-16BE, UTF-32) düzgün bir şekilde arayamaz.

Ancak, TYPE komutu BOM ile UTF-16LE'yi tek baytlık karakter kümesine dönüştürür, bu nedenle aşağıdaki gibi bir komut BOM ile UTF-16LE ile çalışır.

type unicode.txt|findstr "search"

Etkin kod sayfanız tarafından desteklenmeyen Unicode kod noktalarının ?karakterlere dönüştürüleceğini unutmayın .

Arama dizeniz yalnızca ASCII içerdiği sürece UTF-8'i aramak mümkündür. Ancak, çok baytlık UTF-8 karakterlerinin konsol çıktıları doğru olmaz. Ancak çıktıyı bir dosyaya yönlendirirseniz, sonuç UTF-8'i doğru şekilde kodlar. UTF-8 dosyası bir Malzeme Listesini içeriyorsa, Malzeme Listesinin ilk satırın bir parçası olarak kabul edileceğini ve bu satırın başlangıcıyla eşleşen bir aramayı başlatabileceğini unutmayın.

Arama dizenizi UTF-8 kodlu bir arama dosyasına (BOM'suz) koyarsanız ve / G seçeneğini kullanırsanız çok baytlık UTF-8 karakterlerini aramak mümkündür.

Satır Sonu
FINDSTR, her <LF> 'den hemen sonra satırları keser. <CR> 'nin varlığı veya yokluğunun satır kesmeleri üzerinde hiçbir etkisi yoktur.

Satır sonlarında arama
Beklendiği gibi .normal ifade meta karakteri <CR> veya <LF> ile eşleşmeyecek. Ancak bir komut satırı arama dizesi kullanarak satır sonu arasında arama yapmak mümkündür. Hem <CR> hem de <LF> karakterleri açıkça eşleştirilmelidir. Çok satırlı bir eşleşme bulunursa, maçın yalnızca 1. satırı yazdırılır. FINDSTR daha sonra kaynaktaki 2. satıra iki katına çıkar ve aramaya tekrar başlar - bir tür "ileriye bak" tipi özellik.

TEXT.TXT'in bu içeriğe sahip olduğunu varsayın (Unix veya Windows tarzı olabilir)

A
A
A
B
A
A

Sonra bu senaryo

@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

bu sonuçları verir

1:A
2:A
5:A

/CR: FILE seçeneğini kullanarak satır sonlarında arama yapmak kesin değildir çünkü <CR> veya <LF> ile eşleşmenin tek yolu EOL karakterlerini sandviçleyen normal ifade karakter sınıfı aralık ifadesidir.

• [<TAB>-<0x0B>] <LF> ile eşleşir, ancak <TAB> ve <0x0B> ile de eşleşir

• [<0x0C>-!] <CR> ile eşleşir, ancak <0x0C> ve!

  Not - yukarıdaki karakterleri grafik olarak temsil edemiyorum çünkü regex bayt akışının sembolik gösterimleridir.

Aşağıdaki bölüm 2'de cevap devam etti ...

Cevap yukarıdaki 1. bölümden devam etti - 30.000 karakter cevap sınırına girdim :-(

Sınırlı Normal İfadeler (normal ifade) Desteği
Normal ifadeler için FINDSTR desteği son derece sınırlıdır. YARDIM dokümanlarında yoksa desteklenmez.

Bunun ötesinde, desteklenen normal ifade ifadeleri tamamen standart dışı bir şekilde uygulanmaktadır, öyle ki sonuçlar farklı olabilir, o zaman grep veya perl gibi bir şeyden gelmesi beklenir.

Normal İfade Çizgisi Konumu ^ ve $
^ , giriş akışının başlangıcıyla ve <LF> 'den hemen sonra gelen herhangi bir konumla eşleşir. FINDSTR ayrıca <LF> 'den sonraki satırları da böldüğünden, basit bir "^" ifadesi her zaman bir dosyadaki tüm satırlarla, hatta bir ikili dosyayla eşleşir.

$bir <CR> 'den hemen önceki herhangi bir konumla eşleşir. Bu, içeren bir normal ifade arama dizesinin $Unix stili metin dosyasındaki hiçbir satırla hiçbir zaman eşleşmeyeceği veya <CR> <LF> öğesinin EOL işaretçisi eksikse Windows metin dosyasının son satırıyla eşleşmeyeceği anlamına gelir .

Not - Daha önce tartışıldığı gibi, <CR><LF>kaynakta olmayan FINDSTR'a borulu ve yönlendirilmiş giriş eklenmiş olabilir . Açıkçası bu, kullanan bir normal ifade aramasını etkileyebilir $.

Karakterlerden önce ^veya sonra herhangi bir arama dizesi $her zaman bir eşleşme bulamaz.

Konum Seçenekleri / S / B / X
Konum seçenekleri , değişmez arama dizeleri için de çalışması dışında ^ve $ile aynıdır.

/ B, ^normal ifade arama dizesinin başlangıcındaki ile aynı işlevi görür .

/ E, $normal ifade arama dizesinin sonundakiyle aynı işlevi görür .

/ X, normal ifade arama dizesinin ^başında ve $sonunda olmasıyla aynı işlevi görür .

Normal ifade kelime sınırı
\< normal ifadedeki ilk terim olmalıdır. Normal ifade, başka karakterler önüne gelirse hiçbir şeyle eşleşmez. \<ya girişin başlangıcına, bir satırın başlangıcına (bir <LF> 'den hemen sonraki konum) ya da herhangi bir "sözcük olmayan" karakteri hemen takip eden konuma karşılık gelir. Sonraki karakterin "kelime" karakteri olması gerekmez.

\>normal ifadedeki son terim olmalıdır. Normal ifade, başka karakterler izliyorsa hiçbir şeyle eşleşmez. \>ya girişin sonuna, bir <CR> 'den hemen önceki pozisyona ya da herhangi bir "kelime dışı" karakterden hemen önceki pozisyona karşılık gelir. Önceki karakterin bir "kelime" karakteri olması gerekmez.

İşte ondalık bayt kodu olarak gösterilen "sözcük olmayan" karakterlerin tam listesi. Not - bu liste bir ABD makinesinde derlenmiştir. Diğer dillerin bu listede ne gibi etkileri olabileceğini bilmiyorum.

001   028   063   179   204   230
002   029   064   180   205   231
003   030   091   181   206   232
004   031   092   182   207   233
005   032   093   183   208   234
006   033   094   184   209   235
007   034   096   185   210   236
008   035   123   186   211   237
009   036   124   187   212   238
011   037   125   188   213   239
012   038   126   189   214   240
014   039   127   190   215   241
015   040   155   191   216   242
016   041   156   192   217   243
017   042   157   193   218   244
018   043   158   194   219   245
019   044   168   195   220   246
020   045   169   196   221   247
021   046   170   197   222   248
022   047   173   198   223   249
023   058   174   199   224   250
024   059   175   200   226   251
025   060   176   201   227   254
026   061   177   202   228   255
027   062   178   203   229

Normal ifade karakter sınıfı aralıkları [xy]
Karakter sınıfı aralıkları beklendiği gibi çalışmıyor. Şu soruya bakın: findstr neden davayı düzgün işlemiyor (bazı durumlarda)? , bu yanıtla birlikte: https://stackoverflow.com/a/8767815/1012053 .

Sorun FINDSTR karakterleri bayt kod değerleri (genellikle ASCII kodu olarak düşünülür, ancak ASCII yalnızca 0x00 - 0x7F tanımlı) tarafından harmanlamıyor olmasıdır. Normal ifade uygulamalarının çoğu [AZ] harfini büyük harf İngiliz harfleri olarak görür. Ancak FINDSTR, SORT'un nasıl çalıştığına kabaca karşılık gelen bir karşılaştırma dizisi kullanır. Bu yüzden [AZ], büyük ve küçük harf ("a" hariç) yanı sıra aksanlı İngilizce olmayan alfa karakterlerin tamamını içerir.

Aşağıda, normal ifade sınıfı sınıf aralıkları oluşturmak için FINDSTR tarafından kullanılan harmanlama sırasına göre sıralanmış, FINDSTR tarafından desteklenen tüm karakterlerin tam bir listesi bulunmaktadır. Karakterler ondalık bayt kod değeri olarak gösterilir. Karakter dizisi sayfa 437 kullanılarak görüntüleniyorsa harmanlama sırasının en anlamlı olduğuna inanıyorum. Not - bu liste bir ABD makinesinde derlenmiştir. Diğer dillerin bu listede ne gibi etkileri olabileceğini bilmiyorum.

001
002
003
004
005
006
007
008
014
015
016
017
018           
019
020
021
022
023
024
025
026
027
028
029
030
031
127
039
045
032
255
009
010
011
012
013
033
034
035
036
037
038
040
041
042
044
046
047
058
059
063
064
091
092
093
094
095
096
123
124
125
126
173
168
155
156
157
158
043
249
060
061
062
241
174
175
246
251
239
247
240
243
242
169
244
245
254
196
205
179
186
218
213
214
201
191
184
183
187
192
212
211
200
217
190
189
188
195
198
199
204
180
181
182
185
194
209
210
203
193
207
208
202
197
216
215
206
223
220
221
222
219
176
177
178
170
248
230
250
048
172
171
049
050
253
051
052
053
054
055
056
057
236
097
065
166
160
133
131
132
142
134
143
145
146
098
066
099
067
135
128
100
068
101
069
130
144
138
136
137
102
070
159
103
071
104
072
105
073
161
141
140
139
106
074
107
075
108
076
109
077
110
252
078
164
165
111
079
167
162
149
147
148
153
112
080
113
081
114
082
115
083
225
116
084
117
085
163
151
150
129
154
118
086
119
087
120
088
121
089
152
122
090
224
226
235
238
233
227
229
228
231
237
232
234

Normal ifade karakter sınıfı terim sınırı ve HATA
Normalde FINDSTR en fazla 15 karakter sınıfı terimiyle sınırlı olmakla kalmayıp, sınırı aşma girişimini düzgün bir şekilde gerçekleştiremez. 16 veya daha fazla karakter sınıfı terimi kullanıldığında, "Dize Bul (QGREP) Yardımcı Programı bir sorunla karşılaştı ve kapatılması gerekiyor. Sorun için özür dileriz." İleti metni Windows sürümüne bağlı olarak biraz değişir. Başarısız olacak bir FINDSTR örneği:

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]

Bu hata, DosTips kullanıcısı Judago tarafından burada bildirildi . XP, Vista ve Windows 7'de onaylanmıştır.

Normal ifade aramaları 0xFF (ondalık 255) bayt kodu içeriyorsa başarısız olur (ve süresiz olarak askıda kalabilir) 0xFF (ondalık 255)
bayt kodu içeren herhangi bir normal ifade araması başarısız olur. Bayt kodu 0xFF doğrudan eklenmişse veya örtük olarak bir karakter sınıfı aralığına dahil edilmişse başarısız olur. FINDSTR karakter sınıfı aralıklarının bayt kodu değerine göre karakterleri harmanlamadığını unutmayın. Karakter <0xFF>, <space>ve <tab>karakterleri arasındaki harmanlama sırasında nispeten erken görünür . Yani her ikisini de içeren <space>ve <tab>başarısız olacak herhangi bir karakter sınıfı aralığı .

Tam davranış, Windows sürümüne bağlı olarak biraz değişir. 0xFF varsa Windows 7 süresiz olarak kilitleniyor. XP askıda kalmıyor, ancak her zaman bir eşleşme bulamıyor ve bazen aşağıdaki hata iletisini yazdırıyor: "İşlem varolmayan bir boruya yazmaya çalıştı."

Artık bir Vista makinesine erişimim yok, bu yüzden Vista'da test yapamadım.

Normal ifade hatası: .ve [^anySet]Dosya Sonu ile eşleşebilir
Normal ifade .meta karakteri yalnızca <CR>veya dışında herhangi bir karakterle eşleşmelidir <LF>. Dosyadaki son satır <CR>veya ile sonlandırılmazsa Dosya Sonu ile eşleşmesine izin veren bir hata vardır <LF>. Ancak, .boş bir dosyayla eşleşmez.

Örneğin, xsonlandırılmadan <CR>veya tek bir satır içeren "test.txt" adlı bir dosya <LF>aşağıdakilerle eşleşir:

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

Bu hata XP ve Win7'de onaylanmıştır.

Aynı şey negatif karakter kümeleri için de geçerli gibi görünüyor. [^abc]Dosya Sonu ile eşleşecek gibi bir şey . Pozitif karakter setleri [abc]iyi çalışıyor gibi görünüyor. Bunu sadece Win7'de test ettim.

findstr bazen büyük dosyalar aranırken beklenmedik şekilde kilitleniyor.

Tam koşulları veya sınır boyutlarını doğrulamamıştım. 2GB'den büyük dosyaların risk altında olabileceğinden şüpheleniyorum.

Bununla karışık deneyimler yaşadım, bu yüzden sadece dosya boyutundan daha fazlası. Böyle bu görünüm üzerindeki bir varyasyon olabilir XP ve Windows 7 yönlendirilen giriş LF ile sona ermemesi halinde ilgili FINDSTR asılı , ama giriş olduğunda bu problem listelerini gösterildiği gibi değil yönlendirildi.

Aşağıdaki komut satırı oturumu (Windows 7), findstr3GB'lık bir dosyayı ararken nasıl kilitlenebileceğini gösterir .

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>

Not: Onaltılık bir düzenleyicide tüm satırların sonlandığını doğruladım CRLF. Tek anormallik, çalışma şekli0x1A nedeniyle dosyanın sonlandırılmasıdır . Ancak, bu anomali "küçük" dosyalarda soruna neden olmadığını unutmayın .copy

Ek testlerle aşağıdakileri onayladım:

• İkili dosya seçeneği copyile kullanılması /b, 0x1Akarakterin eklenmesini önler findstrve 3GB dosyasına asılmaz.
• 3GB dosyasının farklı bir karakterle sonlandırılması da findstrasılmasına neden olur .
• 0x1AKarakteri "küçük" dosya üzerinde herhangi bir soruna neden olmaz. (Benzer şekilde diğer sonlanan karakterler için.)
• CRLFSonra ekleme işlemi 0x1Asorunu çözer. ( LFtek başına muhtemelen yeterli olacaktır.)
• Kullanılması typehalinde boruya dosyayı findstrkapatmadan işler. (Bunun nedeni, herhangi birinin yan etkisi typeveya |ek bir Satır Sonu eklenmesi olabilir.)
• Yönlendirilmiş girişi kullan <da findstraskıda kalmaya neden olur . Ancak bu beklenen bir durumdur; dbenham'ın gönderisinde açıklandığı gibi : "yeniden yönlendirilen girdi bitmelidir LF" .

Birkaç komut parantez içine alındığında ve tüm bloğa yönlendirilen dosyalar olduğunda:

< input.txt (
   command1
   command2
   . . .
) > output.txt

... daha sonra bloktaki komutlar etkin olduğu sürece dosyalar açık kalır, böylece komutlar yeniden yönlendirilen dosyaların dosya işaretçisini taşıyabilir. MORE ve FIND komutlarının her ikisi de Stdin dosya işaretçisini işlemeden önce dosyanın başlangıcına taşır, böylece aynı dosya blok içinde birkaç kez işlenebilir. Örneğin, bu kod:

more < input.txt >  output.txt
more < input.txt >> output.txt

... bununla aynı sonucu verir:

< input.txt (
   more
   more
) > output.txt

Bu kod:

find    "search string" < input.txt > matchedLines.txt
find /V "search string" < input.txt > unmatchedLines.txt

... bununla aynı sonucu verir:

< input.txt (
   find    "search string" > matchedLines.txt
   find /V "search string" > unmatchedLines.txt
)

FINDSTR farklıdır; o mu değil mevcut pozisyonundan Stdin dosya hareket ettirin. Örneğin, bu kod bir arama satırından sonra yeni bir satır ekler:

call :ProcessFile < input.txt
goto :EOF

:ProcessFile
   rem Read the next line from Stdin and copy it
   set /P line=
   echo %line%
   rem Test if it is the search line
   if "%line%" neq "search line" goto ProcessFile
rem Insert the new line at this point
echo New line
rem And copy the rest of lines
findstr "^"
exit /B

Bu örnekte , yeniden yönlendirilen bir dosyanın dosya işaretçisini bu örnekte gösterildiği gibi taşımamıza izin veren yardımcı bir program yardımıyla iyi bir şekilde kullanabiliriz .

Bu davranış ilk kez bu yazı jeb tarafından bildirildi .

EDIT 2018-08-18 : Yeni FINDSTR hatası bildirildi

FINDSTR komutu, bu komut karakterleri renkli göstermek için kullanıldığında VE böyle bir komutun çıktısı CON aygıtına yeniden yönlendirildiğinde garip bir hata var. Metni renkli göstermek için FINDSTR komutunu kullanma hakkında ayrıntılar için bu konuya bakın .

FINDSTR komutunun bu biçiminin çıktısı CON'a yönlendirildiğinde, metin istenen renkte çıktılandıktan sonra garip bir şey olur: daha kesin bir açıklama metnin siyah arka plan üzerinde siyah metin olarak çıktı. Tüm ekranın ön plan ve arka plan renklerini sıfırlamak için COLOR komutunu kullanırsanız orijinal metin görünür. Ancak, metin "görünmez" olduğunda bir SET / P komutu yürütebiliriz, böylece girilen tüm karakterler ekranda görünmez. Bu davranış, parola girmek için kullanılabilir.

@echo off
setlocal

set /P "=_" < NUL > "Enter password"
findstr /A:1E /V "^$" "Enter password" NUL > CON
del "Enter password"
set /P "password="
cls
color 07
echo The password read is: "%password%"

Dosya adında en tire (-) veya em tire (-) kullanılırken ilk cevapta aranacak veri kaynağı bölümü ile ilgili bir hata bildirmek istiyorum .

Daha spesifik olarak, ilk seçeneği - argüman olarak belirtilen dosya adları kullanmak üzereyseniz , dosya bulunmaz. Yönlendirme yoluyla 2 - stdin seçeneğini veya bir kanaldan 3 - veri akışını kullandığınız anda findstr dosyayı bulacaktır.

Örneğin, bu basit toplu komut dosyası:

echo off
chcp 1250 > nul
set INTEXTFILE1=filename with – dash.txt
set INTEXTFILE2=filename with — dash.txt

rem 3 way of findstr use with en dashed filename
echo.
echo Filename with en dash:
echo.
echo 1. As argument
findstr . "%INTEXTFILE1%"
echo.
echo 2. As stdin via redirection
findstr . < "%INTEXTFILE1%"
echo.
echo 3. As datastream from a pipe
type "%INTEXTFILE1%" | findstr .
echo.
echo.
rem The same set of operations with em dashed filename
echo Filename with em dash:
echo.
echo 1. As argument
findstr . "%INTEXTFILE2%"
echo.
echo 2. As stdin via redirection
findstr . < "%INTEXTFILE2%"
echo.
echo 3. As datastream from a pipe
type "%INTEXTFILE2%" | findstr .
echo.

pause

yazdıracak:

En dash ile dosya adı:

1. FINDSTR bağımsız değişkeni olarak
   : - dash.txt ile dosya adı açılamıyor

2. Yönlendirme yoluyla stdin olarak
   ben bir tire ile dosyayım.

3. Bir borudan veri akışı olarak
   en tireli dosyayım.

Em tire ile dosya adı:

1. FINDSTR bağımsız değişkeni olarak
   : - dash.txt ile dosya adı açılamıyor

2. Yönlendirme yoluyla stdin olarak
   ben bir em tire dosya.

3. Bir borudan veri akışı olarak
   em tire ile dosyayım.

Umarım yardımcı olur.

M.

findstrKomut setleri ErrorLevel(veya çıkış kodu) hiç geçersiz veya uyumsuz anahtarlar ve hiçbir arama dizesi geçerli uzunluğu sınırı aşıyor orada verilen aşağıdaki değerlerden birine:

• 0 belirtilen tüm dosyalar boyunca bir satırda en az bir eşleşme ile karşılaşıldığında;
• 1 aksi takdirde;

Bir satır aşağıdaki durumlarda bir eşleşme içerdiği kabul edilir:

• Hiçbir /Vseçenek verilmiş ve arama ifadesi bir kez en az meydana gelir;
• /Vseçeneği verilir ve arama ifadesi oluşmaz;

O Bu araçlar /Vseçenek de değişir döndü ErrorLevel, ama yok değil sadece döner!

Örneğin, bir dosya var ne zaman test.txtdizesini içeren bunlardan biri iki çizgi ile textancak diğeriyse değil, hem findstr "text" "test.txt"ve findstr /V "text" "test.txt"bir dönüş ErrorLevelait 0.

Temel olarak şunu söyleyebilirsiniz: findstren az bir satır döndürürse , başka bir değere ErrorLevelayarlanır .01

O Not /Mseçenek etkilemez ErrorLevel, sadece değiştirir çıkış değerini.

(Sadece bütünlük uğruna: findkomut , /Vseçeneğe göre tam olarak aynı şekilde davranır ErrorLevelve /Cseçenek etkilemez ErrorLevel.)

FINDSTR'ın tanımladığım ve çözdüğüm bir renk hatası var /superuser/1535810/is-there-a-better-way-to-mitigate-this-obscure-color-bug-when-piping-to -findstr / 1538802? noredirect = 1 # comment2339443_1538802

Bu iş parçacığını özetlemek için, hata, girdinin parantez içinde bir kod bloğu içinde FINDSTR'a iletilmesi durumunda, satır içi ANSI çıkış renk kodlarının daha sonra yürütülen komutlarda çalışmayı durdurmasıdır. Satır içi renk kodlarına bir örnek: echo %magenta%Alert: Something bad happened%yellow%(macenta ve sarı .bat dosyasında daha önce karşılık gelen ANSI kaçış renk kodları olarak tanımlanan değişkenlerdir).

Benim ilk çözüm FINDSTR sonra bir hiçbir şey alt yordamı çağırmak oldu. Bir şekilde arama veya geri dönüş sıfırlanması gereken her şeyi "sıfırlar".

Daha sonra muhtemelen daha verimli olan başka bir çözüm keşfettim: Aşağıdaki örnekte olduğu gibi FINDSTR ifadesini parantez içine echo success | ( FINDSTR /R success ) yerleştirin : FINDSTR ifadesini iç içe bir kod bloğuna yerleştirmek, FINDSTR'ın renk kodu hatasını yuvalanmış dışını etkilemeyecek şekilde izole ediyor gibi görünüyor blok. Belki de bu teknik diğer istenmeyen FINDSTR yan etkilerini de çözecektir .

/ D birden çok dizin için ipucu: dizin listenizi arama dizesinin önüne yerleştirin. Bunların hepsi çalışır:

findstr /D:dir1;dir2 "searchString" *.*
findstr /D:"dir1;dir2" "searchString" *.*
findstr /D:"\path\dir1\;\path\dir2\" "searchString" *.*

Beklendiği gibi, dizinleri ile başlatmazsanız yol konuma göre olur \. "Dizin adlarında boşluk yoksa yolu çevrelemek isteğe bağlıdır. Bitiş \isteğe bağlıdır. Konumun çıktısı, verdiğiniz yolu içerir. Dizin listesini çevreleyen veya içermeyen çalışır ".