Передмова
Багато інформації в цій відповіді зібрано на основі експериментів, проведених на машині Vista. Якщо прямо не вказано інше, я не підтвердив, чи стосується ця інформація до інших версій Windows.
Вихід FINDSTR
Документація ніколи не намагається пояснювати вихід FINDSTR. Це натякає на те, що друкуються відповідні рядки, але нічого більше.
Формат виведення рядка відповідності такий:
ім'я файлу: рядокNumber: lineOffset: текст
де
fileName: = Ім'я файлу, що містить рядок відповідності. Ім'я файлу не друкується, якщо запит був явним чином для одного файлу, або при пошуку вхідного каналу або перенаправленого вводу. При надрукуванні ім'я файлу завжди буде містити будь-яку інформацію про шлях. Додаткова інформація про шлях буде додана, якщо використовується/Sпараметр. Друкований шлях завжди є відносно наданого шляху або відносно поточного каталогу, якщо його немає.
Примітка - префікс імені файлу можна уникнути при пошуку декількох файлів за допомогою нестандартних (і погано документованих) групових символів < і >. Точні правила роботи цих макетів можна знайти тут . Нарешті, ви можете ознайомитись із цим прикладом того, як нестандартні макіяжі працюють з FINDSTR .
lineNumber: = Номер рядка відповідного рядка, представлений у вигляді десяткового значення з 1, що представляє 1-й рядок вводу. Друкується лише якщо/Nвказана опція.
lineOffset: = Десяткове байтове зміщення початку відповідного рядка, причому 0 представляє 1-й символ першого рядка. Друкується лише якщо/Oвказана опція. Це не зміщення матчу в рядку. Це кількість байтів від початку файлу до початку рядка.
text = Двійкове представлення відповідного рядка, включаючи будь-який <CR> та / або <LF>. Від бінарного виводу нічого не залишається, так що цей приклад, який відповідає всім рядкам, створить точну бінарну копію вихідного файлу.
FINDSTR "^" FILE >FILE_COPY
Параметр / A встановлює колір файлуName :, lineNumber :, and lineOffset: only output. Текст відповідного рядка завжди виводиться з поточним кольором консолі. Параметр / A діє лише тоді, коли вихід відображається безпосередньо на консолі. Параметр / A не має ефекту, якщо вихідний файл буде переспрямований у файл або на трубопроводі. Дивіться редакцію 2018-08-18 у відповіді Aacini для опису поведінки баггі, коли вихід перенаправляється на CON.
Більшість керуючих символів та багато розширених символів ASCII відображаються у вигляді крапок на XP
FINDSTR на XP, на екрані відображається більшість недрукованих контрольних символів із відповідних ліній у вигляді крапок (періодів). Наступні контрольні символи - винятки; вони відображаються як самі: вкладка 0x09, 0x0A LineFeed, вертикальна вкладка 0x0B, подача форми 0x0C, повернення перевезення 0x0D.
XP FINDSTR також перетворює ряд розширених символів ASCII в крапки. Розширені символи ASCII, які відображаються у вигляді точок у XP, такі ж, як і ті, що трансформуються, коли вони надходять у командному рядку. Дивіться розділ "Обмеження символів для параметрів командного рядка - Розширене перетворення ASCII" , пізніше в цій публікації
Контрольні символи та розширений ASCII не конвертуються в точки в XP, якщо вихідний конвеєр, перенаправлений у файл або в пункті FOR IN ().
Vista та Windows 7 завжди відображають усі символи як себе, ніколи не крапки.
Коди повернення (ERRORLEVEL)
- 0 (успіх)
- Збіг знайдено принаймні в одному рядку принаймні одного файлу.
- 1 (збій)
- У жодному рядку будь-якого файлу не знайдено відповідності.
- Недійсний колір, визначений
/A:xxопцією
- 2 (помилка)
- Несумісні варіанти
/Lта /Rобидва вказані
- Відсутня аргумент після
/A:, /F:, /C:, /D:, або/G:
- Файл, вказаний
/F:fileабо /G:fileне знайдений
- 255 (помилка)
Джерело даних для пошуку (оновлено на основі тестів з Windows 7)
Findstr може шукати дані лише з одного з таких джерел:
імена файлів, вказані як аргументи та / або з використанням /F:fileопції.
stdin через перенаправлення findstr "searchString" <file
потік даних з труби type file | findstr "searchString"
Аргументи / параметри мають перевагу перед перенаправленням, що має перевагу над трубопровідними даними.
Аргументи імені файлів /F:fileможуть бути об'єднані. Можна використовувати декілька аргументів імені файлів. Якщо /F:fileвказано кілька варіантів, використовується лише останній. Польові картки дозволяються в аргументах імен файлів, але не у файлі, на який вказує /F:file.
Джерело рядків пошуку (оновлено на основі тестів з Windows 7)
Параметри /G:fileта /C:stringпараметри можуть поєднуватися. /C:stringМожна вказати кілька варіантів. Якщо /G:fileвказано кілька варіантів, використовується лише останній. Якщо використовується /G:fileабо /C:stringвикористовується, всі аргументи, що не є опціями, вважаються файлами для пошуку. Якщо ні, /G:fileні/C:string не використовується, то перший аргумент, що не є варіантом, трактується як список пошукових термінів, обмежений пробілом.
Імена файлів не повинні цитуватися у файлі під час використання /F:FILEпараметра.
Імена файлів можуть містити пробіли та інші спеціальні символи. Більшість команд вимагають, щоб такі імена файлів були цитовані. Але параметр FINDSTR /F:files.txtвимагає, щоб назви файлів у файлах.txt НЕ котирувались. Файл не буде знайдено, якщо ім'я буде вказано.
BUG - Короткі/D/S
файли файлів 8.3 можуть порушити параметри та параметри Як і у всіх командах Windows, FINDSTR намагатиметься зіставити як довге ім'я, так і коротке 8.3 ім'я під час пошуку файлів для пошуку. Припустимо, що поточна папка містить такі непорожні файли:
b1.txt
b.txt2
c.txt
Наступна команда успішно знайде всі 3 файли:
findstr /m "^" *.txt
b.txt2відповідає тому, що відповідна коротка назва B9F64~1.TXTвідповідає. Це відповідає поведінці всіх інших команд Windows.
Але помилка з параметрами /Dта /Sпараметрами змушує знаходити лише наступні командиb1.txt
findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt
Не вдалося b.txt2знайти помилку , а також усі імена файлів, які впорядковуються b.txt2в межах одного каталогу. a.txtЗнайдені додаткові файли, які сортували раніше, як , наприклад. Додаткові файли, які сортуються пізніше, як-от d.txt, пропускаються, коли помилка була запущена.
Кожен шуканий каталог обробляється незалежно. Наприклад, /Sопція успішно розпочнеться пошук у дочірній папці після того, як не вдалося знайти файли у батьківській програмі, але як тільки помилка спричиняє пропущення короткого імені файлу у дитини, то всі наступні файли в цій дочірній папці також будуть пропущені .
Команди працюють без помилок, якщо однакові імена файлів створюються на машині, де вимкнено генерацію імен NTFS 8.3. Звичайно b.txt2, не знайдеться, але c.txtбуло б знайдено належним чином.
Не всі короткі імена викликають помилку. Усі випадки помилок, які я бачив, містять розширення, яке перевищує 3 символи, з коротким ім'ям 8.3, яке починається так само, як і звичайне ім'я, яке не вимагає 8.3 імені.
Помилка підтверджена в XP, Vista та Windows 7.
Недруковані символи та /Pопція
Ця /Pопція змушує FINDSTR пропустити будь-який файл, який містить будь-який із наступних десяткових байтових кодів:
0-7, 14-25, 27-31.
По-іншому, /Pпараметр буде пропускати лише файли, що містять символи управління, які не можна друкувати. Контрольні символи - це коди, менші або рівні 31 (0x1F). FINDSTR розглядає такі друковані символи як друковані:
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)
Всі інші символи управління розглядаються як недруковані, наявність яких спричиняє /Pможливість пропустити файл.
Трубопровідний та перенаправлений вхід, можливо, <CR><LF>додаються.
Якщо вхід вкладено, а останнього символу потоку немає <LF>, то FINDSTR автоматично додасть <CR><LF>до входу. Це було підтверджено на XP, Vista та Windows 7. (Я вважав, що трубка Windows несе відповідальність за зміну входу, але з тих пір я виявив, що FINDSTR насправді робить модифікацію.)
Те саме стосується перенаправленого вводу на Vista. Якщо останнього символу файлу, використовуваного як перенаправлений вхід, немає <LF>, то FINDSTR автоматично додає <CR><LF>до вводу. Однак XP та Windows 7 не змінюють перенаправлений вхід.
FINDSTR висить на XP та Windows 7, якщо переспрямований вхід не закінчується.<LF>
Це противна "особливість" для XP та Windows 7. Якщо останній символ файлу, який використовується як перенаправлений вхід, не закінчується <LF>, то FINDSTR буде зависати нескінченно раз на ньому доходить до кінця переспрямованого файлу.
Останній рядок даних Piped може бути проігнорований, якщо він складається з одного символу
Якщо вхід введено в дію і останній рядок складається з одного символу, за яким не слідує <LF>, то FINDSTR повністю ігнорує останній рядок.
Приклад - перша команда з одним символом і не <LF>дає збіги, але друга команда з двома символами працює добре, як і третя команда, що має один символ із закінченням нового рядка.
> set /p "=x" <nul | findstr "^"
> set /p "=xx" <nul | findstr "^"
xx
> echo x| findstr "^"
x
Повідомляє користувач DosTips Sponge Belly при новому помилку findstr . Підтверджено на XP, Windows 7 та Windows 8. Ще не чув про Vista. (У мене більше немає Vista для тестування).
Синтаксис
опцій Опції можуть бути префіксальні або з, /або -
Опції можуть бути об'єднані після одиничного /або -. Однак список об'єднаних опцій може містити щонайменше один варіант багатохарактерних функцій, такий як OFF або F :, а опція з декількома символами повинна бути останньою опцією у списку.
Нижче наведені всі еквівалентні способи вираження регрес-пошуку, нечутливого до регістру, для будь-якого рядка, що містить і "привіт", і "до побачення" в будь-якому порядку
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
Обмеження довжини пошукових рядків
У Vista максимальна допустима довжина для одного рядка пошуку становить 511 байт. Якщо будь-яка рядок пошуку перевищує 511, то результат - FINDSTR: Search string too long.помилка з ERRORLEVEL 2.
Під час регулярного пошуку виразів максимальна довжина рядка пошуку становить 254. Регулярний вираз довжиною від 255 до 511 призведе до FINDSTR: Out of memoryпомилки з ERRORLEVEL 2. Помилка призводить до правильної довжини виразу> 511 FINDSTR: Search string too long..
У Windows XP довжина пошукового рядка, мабуть, коротша. Помилка Findstr: "Пошуковий рядок занадто довгий": Як витягнути і підрівняти підрядку в циклі "for"?
Ліміт XP становить 127 байт як для прямого пошуку, так і для регулярного вибору.
Обмеження довжини рядка
Файли, вказані як аргумент командного рядка, або за допомогою параметра / F: FILE не мають відомого обмеження довжини рядка. Пошукові запити були успішно запущені у файлі 128 Мб, який не містив жодного <LF>.
Трубопровідні дані та перенаправлений вхід обмежені 8191 байтом на рядок. Цей ліміт є "особливістю" FINDSTR. Це не властиво трубам або перенаправленню. FINDSTR, використовуючи переспрямований stdin або трубопровідний вхід, ніколи не буде відповідати жодному рядку, що становить> = 8k байтів. Рядки> = 8k генерують повідомлення про помилку в stderr, але ERRORLEVEL все ще дорівнює 0, якщо рядок пошуку знайдено принаймні в одному рядку щонайменше в одному файлі.
Тип пошуку за замовчуванням: Literal vs Regular Expression
/C:"string" - Типовим є / L literal. Явне поєднання параметра / L з / C: "рядок", безумовно, працює, але є зайвим.
"string argument"- За замовчуванням залежить зміст самого першого рядка пошуку. (Пам’ятайте, що <space> використовується для розмежування рядків пошуку.) Якщо перший рядок пошуку є дійсним регулярним виразом, що містить принаймні один невідбутий мета-символ, то всі рядки пошуку розглядаються як регулярні вирази. В іншому випадку всі рядки пошуку трактуються як буквальні. Наприклад, "51.4 200"трактуватимуться як два регулярних вирази, тому що перший рядок містить непотрібну крапку, тоді як "200 51.4"буде розглянуто як два літерали, оскільки перший рядок не містить мета-символів.
/G:file- За замовчуванням залежить вміст першого не порожнього рядка у файлі. Якщо перший рядок пошуку є дійсним регулярним виразом, який містить щонайменше один невідбутий мета-символ, то всі рядки пошуку розглядаються як регулярні вирази. В іншому випадку всі рядки пошуку трактуються як буквальні.
Рекомендація - Завжди чітко вказуйте /Lбуквальний параметр або параметр /Rрегулярного вираження при використанні "string argument"або /G:file.
BUG - Вказівка декількох буквальних рядків пошуку може дати ненадійні результати
Наведений нижче простий приклад FINDSTR не в змозі знайти відповідність, хоч і повинен.
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
Ця помилка була підтверджена в Windows Server 2003, Windows XP, Vista та Windows 7.
На основі експериментів, FINDSTR може не вдатися, якщо будуть виконані всі наступні умови:
- Для пошуку використовується декілька буквальних рядків пошуку
- Рядки пошуку мають різну довжину
- Короткий рядок пошуку має деяку кількість перекриття з довшою пошуковою рядком
- Пошук відрізняється від регістру (немає
/Iваріантів)
У кожному невдачі, який я бачив, це завжди одна з коротших рядків пошуку, яка не працює.
Для отримання додаткової інформації див. Чому цей приклад FINDSTR з кількома буквальними рядками пошуку не відповідає?
Котирування та зворотні коси в аргументах командного рядка
Примітка - коментарі користувача MC ND відображають фактично жахливо складні правила для цього розділу. Задіяні 3 окремі фази розбору:
- Перший cmd.exe може вимагати, щоб деякі цитати не були використані як ^ "(насправді нічого не стосується FINDSTR)
- Далі FINDSTR використовує аналізатор аргументів MS C / C ++ до 2008 року , який має спеціальні правила для "та \
- Після завершення аналізатора аргументів, FINDSTR додатково розглядає \, а потім буквено-цифровий символ як буквальний, але \ з наступним не-альфа-числовим символом як символ втечі
Решта цього виділеного розділу не на 100% вірна. Він може слугувати посібником для багатьох ситуацій, але вищезазначені правила потрібні для повного розуміння.
Уникнення
цитати в рядках пошуку в командному рядку Цитати в рядках пошуку в командному рядку повинні бути усунені з подібною косою рисою
\". Це справедливо як для буквальних, так і для регулярних виразів пошуку. Цю інформацію було підтверджено в XP, Vista та Windows 7.
Примітка. Цитата також може знадобитися уникати для аналізатора CMD.EXE, але це не має нічого спільного з FINDSTR. Наприклад, для пошуку однієї цитати ви можете використовувати:
FINDSTR \^" file && echo found || echo not found
Уникнення зворотного косого ряду в рядках пошуку
в прямому рядку командного рядка Зворотний проріз у рядку пошуку буквально може бути представлений як
\або як \\. Вони, як правило, рівнозначні. (Можливо, у Vista є випадкові випадки, коли зворотну косу рису потрібно завжди уникати, але у мене більше немає машини для перевірки) .
Але є деякі особливі випадки:
При пошуку послідовних зворотних косих рис, все , крім останнього необхідно екранувати. Останній зворотний нахил може необов'язково уникнути.
\\можна кодувати як \\\або\\\\\\\можна кодувати як \\\\\або\\\\\\
Пошук одного або декількох косих рисок перед цитатою химерний. Логіка підказує, що цитата повинна бути відхилена, і кожен з провідних зворотних косої риски повинен бути уникнути, але це не працює! Натомість, кожен з провідних косих косих ринків повинен бути подвійним, а цитата - нормальною:
\" повинні бути кодовані як \\\\\"\\" повинні бути кодовані як \\\\\\\\\"
Як було зазначено раніше, одна або кілька котирувань, що увійшли, можуть також вимагати переходу ^для аналізатора CMD
Інформація в цьому розділі підтверджена в XP та Windows 7.
Уникнення зворотного косого ряду в рядках пошуку регулярного вираження командного рядка
Тільки Vista: зворотна коса в регулярному виразі повинна бути або подвійною \\\\, а або одинаковою втечею в наборі класів символів, як
[\\]
XP та Windows 7: Зворотна косою рисою завжди може бути представлена як [\\]. Зазвичай це може бути представлено як \\. Але це ніколи не спрацьовує, якщо зворотний косий передує уникненій цитаті.
Один або декілька косих косих рядків, що вийшли вперед, або повинні бути подвійними, або ж закодованими як [\\]
\"може кодуватися як \\\\\"або[\\]\"\\"можуть бути кодовані як \\\\\\\\\"або [\\][\\]\"або\\[\\]\"
Уникнення
котирування та зворотного косу в межах / G: ФАЙЛ буквальних рядків пошуку. Автономні лапки та зворотні косої риски в прямому рядку пошуку, вказаному в / G: файл не потрібно уникати, але вони можуть бути.
"і \"є рівнозначними.
\і \\є рівнозначними.
Якщо наміром знайти \\, потрібно хоча б уникнути провідного косого кута. І те, \\\і \\\\робота.
Якщо наміром знайти \ ", то потрібно принаймні ухилити провідну косу рису \\" і \\\"працювати.
Уникнення котирування і зворотного косу в межах / G: ФАЙЛ пошуку рядків пошуку регулярного виразів
Це єдиний випадок, коли послідовності втечі працюють відповідно до документації, як очікувалося. Цитата не є метасимволом регулярних виразів, тому її не потрібно уникати (але може бути). Зворотна коса - це метасимвол регулярних виразів, тому його потрібно уникати.
Обмеження символів для параметрів командного рядка - Розширене перетворення ASCII
Нульовий символ (0x00) не може відображатися в жодному рядку командного рядка. Будь-який інший байт-символ може відображатися в рядку (0x01 - 0xFF). Однак FINDSTR перетворює багато розширених символів ASCII, які він знаходить у параметрах командного рядка, в інші символи. Це має великий вплив двома способами:
1) Багато розширених символів ASCII не відповідають собі, якщо їх використовувати як рядок пошуку в командному рядку. Це обмеження є однаковим для пошуку в прямому сенсі та регулярному вираженні. Якщо рядок пошуку повинен містити розширений ASCII, то/G:FILE замість цього слід використовувати параметр.
2) FINDSTR може не знайти файл, якщо ім'я містить розширені символи ASCII і ім'я файлу вказано в командному рядку. Якщо файл, який слід шукати, містить розширений ASCII в імені, то /F:FILEзамість цього слід використовувати опцію.
Ось повний перелік розширених перетворень символів ASCII, які FINDSTR виконує у рядках командного рядка. Кожен символ представлений у вигляді знаку коду у десятковому байті. Перший код являє собою символ, що подається в командному рядку, а другий код являє символ, в який він перетворений. Примітка - цей список був складений на машині США. Я не знаю, який вплив можуть мати інші мови на цей список.
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
Будь-який символ> 0, який не знаходиться у списку вище, трактується як сам, включаючи <CR>та < LF>. Найпростіший спосіб включити непарні символи, як <CR>і, <LF>це ввести їх у змінну середовища та використовувати затримку розширення в аргументі командного рядка.
Обмеження символів для рядків, знайдених у файлах, визначених параметрами / G: FILE та / F: FILE Параметр
nul (0x00) може відображатися у файлі, але він функціонує як термінатор рядка C. Будь-які символи після нульового символу трактуються як інший рядок, як ніби вони знаходяться в іншому рядку.
<CR>І <LF>символи розглядаються як лінійні термінатори , які завершуються рядки, і не включаються до рядка.
Всі інші однобайтові символи ідеально включаються в рядок.
Пошук файлів Unicode
FINDSTR не може належним чином шукати більшість Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), оскільки він не може шукати нульові байти, а Unicode, як правило, містить багато нульових байтів.
Однак команда TYPE перетворює UTF-16LE з BOM в однобайтовий набір символів, тому така команда, як нижче, буде працювати з UTF-16LE з BOM.
type unicode.txt|findstr "search"
Зауважте, що точки коду Unicode, які не підтримуються вашою активною кодовою сторінкою, будуть перетворені в ?символи.
Можна шукати UTF-8 до тих пір, поки у вашій пошуковій рядці є лише ASCII. Однак консольний вихід будь-яких багатобайтових символів UTF-8 не буде правильним. Але якщо перенаправити вихід на файл, то результат буде правильно закодований UTF-8. Зауважте, що якщо файл UTF-8 містить BOM, то BOM вважатиметься частиною першого рядка, який може скинути пошук, що відповідає початку рядка.
Можна шукати багатобайтові символи UTF-8, якщо ви введете пошукову рядок у закодований файл UTF-8 (без BOM) та скористаєтесь опцією / G.
Кінець рядка
FINDSTR розбиває рядки відразу після кожного <LF>. Наявність або відсутність <CR> не впливає на розриви рядків.
Пошук по розривах рядків
Як і очікувалося, .метахарактер регулярних вирівнювань не буде відповідати <CR> або <LF>. Але можна шукати перерву рядка за допомогою рядка пошуку командного рядка. І символи <CR>, і <LF> повинні бути чітко узгоджені. Якщо знайдено багаторядковий збіг, друкується лише 1-й рядок відповідності. Потім FINDSTR подвоюється назад до другого рядка в джерелі і починає пошук знову заново - на зразок функції типу "погляд вперед".
Припустимо, у TEXT.TXT є цей вміст (це може бути стиль Unix або Windows)
A
A
A
B
A
A
Тоді цей сценарій
@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
дає ці результати
1:A
2:A
5:A
Пошук через розриви рядків за допомогою параметра / G: FILE є неточним, оскільки єдиний спосіб зіставити <CR> або <LF> - це вираз діапазону символів класу регулярних виразів, який затискає символи EOL.
[<TAB>-<0x0B>] відповідає <LF>, але він також відповідає <TAB> і <0x0B>
[<0x0C>-!] відповідає <CR>, але він також відповідає <0x0C> і!
Зауважте - вищевказані символічні зображення байтового потоку регулярних виразів, оскільки я не можу графічно представити символи.
Відповідь продовжено в частині 2 нижче ...
grepяких є дуже добре зрозуміло і документований :-) Див stackoverflow.com/questions/2635740 / ... , наприклад.