Список аргументів занадто довгий для ls

Я отримую таку помилку під час спроби ls *.txt | wc -lкаталогу, який містить багато файлів:

-bash: /bin/ls: Argument list too long

Чи залежить поріг цього "списку аргументів" від дистрибутива чи специфіки комп'ютера? Зазвичай я б передав результат такого великого результату в деякі інші команди ( wc -lнаприклад), тому я не переймаюся межами терміналу.

Занадто довгий список аргументів повідомлення про помилку надходить із * з ls *.txt.

Ці обмеження є безпекою як для бінарних програм, так і для вашого ядра. На цій сторінці ви побачите більше інформації про неї, а також про те, як використовується та обчислюється.

Немає такого обмеження щодо розміру труби. Таким чином, ви можете просто написати цю команду:

find -type f -name '*.txt'  | wc -l

NB: На сучасних Linux, дивні символи в іменах файлів (наприклад , рядок) будуть екрановані з допомогою інструментів lsабо find, але по- , як і раніше відображається від * . Якщо ви перебуваєте на старому Unix, вам знадобиться ця команда

find -type f -name '*.txt' -exec echo \;  | wc -l

NB2: Мені було цікаво, як можна створити файл із новим рядком у своєму імені. Це не так важко, як тільки ви знаєте хитрість:

touch "hello
world"

В основному це залежить від вашої версії ядра Linux.

Ви повинні мати можливість бачити ліміт для вашої системи, запустивши

getconf ARG_MAX

який повідомляє вам про максимальну кількість байтів, які може мати командний рядок після розширення оболонкою.

У Linux <2.6.23 ліміт зазвичай становить 128 КБ.

В Linux> = 2.6.25 ліміт становить або 128 КБ, або 1/4 розміру вашої стеки (див. ulimit -s), Залежно від того, що більше.

Детальну інформацію див. На головній сторінці execve (2) .

На жаль, трубопровід ls *.txtне вирішить проблему, оскільки ліміт знаходиться в операційній системі, а не в оболонці.

Оболонка розгортає *.txt, потім намагається викликати

exec("ls", "a.txt", "b.txt", ...)

і у вас стільки файлів, що відповідають, *.txtщо ви перевищуєте ліміт 128 КБ.

Вам доведеться зробити щось на кшталт

find . -maxdepth 1 -name "*.txt" | wc -l

замість цього.

(І дивіться коментарі Шона Дж. Гоффа нижче щодо імен файлів, що містять нові рядки.)

Ще одне вирішення:

ls | grep -c '\.txt$'

Незважаючи на те, що lsвиробляє більше продукції, ніж ls *.txtвиробляє (або намагається виробляти), вона не стикається з проблемою "занадто довгий аргумент", тому що ви не передаєте жодних аргументів ls. Зауважте, що це grepмає регулярний вираз, а не шаблон відповідності файлів.

Ви можете скористатися:

ls -U | grep -c '\.txt$'

(припустимо, що ваша версія lsпідтримує цю опцію). Це говорить про lsне сортування його результатів, що може заощадити і час, і пам'ять - і в цьому випадку порядок не має значення, оскільки ви просто підраховуєте файли. Ресурси, витрачені на сортування результатів, зазвичай не значні, але в цьому випадку ми вже знаємо, що у вас дуже велика кількість *.txtфайлів.

І вам слід розглянути можливість реорганізації файлів, щоб у вас не було стільки в одному каталозі. Це може бути, а може і не бути можливим.

MAX_ARG_PAGES представляється параметром ядра. Використання findі xargsє типовою комбінацією для подолання цієї межі, але я не впевнений, що це буде працювати wc.

Передача результатів у find . -name \*\.txtфайл та підрахунок рядків у цьому файлі повинні слугувати вирішенням.

Це може бути брудно, але це працює для моїх потреб та в межах моєї компетенції. Я не думаю, що це працює дуже швидко, але це дозволило мені продовжувати свій день.

ls | grep jpg | <something>

Я отримував 90 000 довгий список jpgs і передав їх на avconv, щоб створити проміжок часу.

Раніше я використовував ls * .jpg | avconv, перш ніж я зіткнувся з цим питанням.