Использование упомянутых вами инструментов + Найти :
Получите процент строк или байт ¹ с Head -n-файлом PERC или Файл PERC ,
где Perc дается ((Count / 5)) ,
Где считается WC -L <файл или WC -C <файл ,
Наконец, напишите выходные данные в соответствии file_20 .

Примечание. Оператор / раундут до ближайшего целого числа, так что любой файл * с линиями / байтами сочетается <5 (следовательно PERC = 0 ) создаст пустой файл * _20 файл.

Получите первые 20% - линии:

mkdir some_dir_name
find . -maxdepth 1 -iname 'file*' -exec sh -c 'head -n $(( $(wc -l < "$0") / 5 )) "$0" > some_dir_name/"$0"_20' {} \;

Получите первые 20% - байты:

mkdir some_dir_name
find . -maxdepth 1 -iname 'file*' -exec sh -c 'head -c $(( $(wc -c < "$0") / 5 )) "$0" > some_dir_name/"$0"_20' {} \;

₁
Обратите внимание, что, в зависимости от макета текста, два метода могут привести к значительному разным результатам, например, Для 10-линии текстового образца:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.


Abstract

Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
ut aliquip ex ea commodo consequat. 

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum...

первые 20% от общего количества строк = первые 2 строки:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.

первые 20% от общего количества байтов = первая строка (усеченная):

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do

Черт. Я написал весь этот большой ответ с помощью тщательно разработанного метода синтаксического анализа архива tar - это было круто. Но я добрался до конца и понял, что в этом нет никакой необходимости. Все, что вам нужно, это sed и небольшая математика оболочки:

set ./file[1-5];i=1 n=;eval "${n:=
}       sed -n  \"$(grep -c '.\|' "$@"|
        sed 's|\(.*\):\(.*\)|\
        $i,$(((\2/5)+(i+=\2)-\2))w \1|
        ')\" <<!$n"'$(cat "$@")'"$n!$n"

Там grep -c подсчитывает строки в любых файлах, которые вы скопировали - я добавил file [1-5 ] - и передает счет в sed , который затем - с небольшой помощью оболочки - пишет свой собственный сценарий. cat обеспечивает ввод через документ.Это потому, что я сомневаюсь в том, что может произойти, если sed откроет и начнет запись в один из файлов, которые cat пытается прочитать в него - также я подозреваю было бы немного лучше обрабатывать буферы, чем канал, в зависимости от размера - но я не слишком ясен в этой части.

Таким образом, все файлы читаются в одном потоке, а w обрабатывает вывод соответствующим образом. Для правильного увеличения номеров файлов требуется небольшая настройка - поэтому grep и eval - ничего страшного. Вот некоторые выходные данные set -x , чтобы показать, что он делает:

+ set ./file1 ./file2 ./file3 ./file4 ./file5
+ i=1 n=
+ + grep -c .\| ./file1 ./file2 ./file3 ./file4 ./file5
        sed s|\(.*\):\(.*\)|\
        $i,$(((\2/5)+(i+=\2)-\2))w \1|

+ eval 
       sed -n  "
        $i,$(((18400/5)+(i+=18400)-18400))w ./file1

        $i,$(((18411/5)+(i+=18411)-18411))w ./file2

        $i,$(((18415/5)+(i+=18415)-18415))w ./file3

        $i,$(((18418/5)+(i+=18418)-18418))w ./file4

        $i,$(((18421/5)+(i+=18421)-18421))w ./file5" <<!
$(cat "$@")
!

+ cat ./file1 ./file2 ./file3 ./file4 ./file5
+ sed -n 
        1,3681w ./file1

        18401,22083w ./file2

        36812,40495w ./file3

        55227,58910w ./file4

        73645,77329w ./file5

Как видите, адреса строк определяются в зависимости от позиции каждого файла в потоке, и они w ritten поскольку они читаются в их соответствующих именах файлов. Однако важно отметить, что при этом не предпринимаются попытки обработать какие-либо непереносимые символы в имени пути - в частности, новые строки в именах путей в этом случае не являются стартером, поскольку команда sed w rite ограничивает имя файла аргументы о новых строках. Ситуацию легко обойти, если необходимо, с помощью ln , если вам это нужно.

Я также должен упомянуть, что существует ограничение на количество w файловых дескрипторов sed , которые могут поддерживаться в одном скрипте. В спецификации указано :

[ sed требуется] для поддержки как минимум десяти отдельных файлов w , что соответствует исторической практике многих реализаций.Реализациям рекомендуется поддерживать больше, но соответствующие приложения не должны превышать этого предела.

Таким образом, описанная выше команда должна быть переносимой в любую систему POSIX для одновременного чтения / записи до 10 файлов. Если бы такие вещи были включены в опубликованный скрипт или приложение, в котором могло бы потребоваться больше, возможно, стоит выполнить несколько проверок перед обработкой реальных данных в / tmp . Например:

: & set '"" "" "" "" "" "" "" "" "" "" ';n='
' f=/tmp/$$$!'_$((i+=1))' MAXw=[num]
while eval "set '$1$1' $1;exec <<!$n\$(((i=0)+\$#))$n!$n 
      i=\$(sed \"$(IFS=\ ;printf "\nw $f%.0s" $1)\")"
      [ "$(($#==i?(_i=i-1):(MAXw=_i)))" -lt "$MAXw" ]
do :;done; rm "/tmp/$$$!"*; unset _i i f n

... который должен достаточно портативно оценить возможности sed в этой области. GNU sed застопорился на 4093 одновременно открытых для меня w файлах примерно за секунду, но это, вероятно, максимум моей системы, и на него может повлиять ulimit также. Когда это было выполнено - поскольку проверка удваивает значение $ i для каждой попытки - $ _ i остается на уровне 2560, а $ i - на 5120. Я по умолчанию для установки $ MAXw более безопасного $ _ i выше при закрытии цикла - в основном потому, что я не уверен, все ли sed s будут правильно устанавливать свой возврат, если они не могут откройте файл w - но читатель может делать с ним все, что захочет.

Обратите внимание, что начальное значение [num] для $ MAXw должно быть фактическим числом - каким бы ни был ваш максимальный размер файлов w , а не буквально [число] .

Еще раз о документе здесь - я считаю это - или что-то в этом роде - хорошей идеей в данном случае. sed должен поддерживать свои дескрипторы записи во время чтения, поэтому я не знаю, что он может делать с идентичными входными / исходящими именами, но я не думаю, что стоит рисковать, когда альтернативы так легко доступны нам.

Мои тестовые файлы были сгенерированы вроде:

for n in 1 2 3 4 5
do : & seq -s "$(printf "%015s--$n--%015s\n\t")" "$!" >"file$n"
done

... который получает довольно последовательные псевдо-случайные числа из ядра в PID заброшенных процессов. Содержимое файла было специально разработано, чтобы указать на несоответствие в разделении. Вот как выглядит набор примеров до и после:

До:

for f in file[1-5]; do
nl -ba "$f" | sed -n '$p;$=;1,3p
'; done

     1  1               --1--             
     2          2               --1--     
     3          3               --1--     
  3681          3681               --1--  
3681
     1  1               --2--             
     2          2               --2--     
     3          3               --2--     
  3683          3683               --2--  
3683
     1  1               --3--             
     2          2               --3--     
     3          3               --3--     
  3684          3684               --3--  
3684
     1  1               --4--             
     2          2               --4--     
     3          3               --4--     
  3684          3684               --4--  
3684
     1  1               --5--             
     2          2               --5--     
     3          3               --5--     
  3685          3685               --5--  
3685

Если форматирование выглядит немного странно, это, вероятно, связано с тем, что seq не вставляет -s строка-разделитель перед первой строкой вывода. Важно то, что sed , seq и nl , похоже, совпадают по номерам строк. В любом случае ...

После: ...

  sed -n 
  1,737w ./file1

  3682,4418w ./file2

  7365,8101w ./file3

  11049,11785w ./file4

  14733,15470w ./file5
  ...
     1  1               --1--           
     2          2               --1--   
     3          3               --1--   
   737          737               --1-- 
737
     1  1               --2--           
     2          2               --2--   
     3          3               --2--   
   737          737               --2-- 
737
     1  1               --3--           
     2          2               --3--   
     3          3               --3--   
   737          737               --3-- 
737
     1  1               --4--           
     2          2               --4--   
     3          3               --4--   
   737          737               --4-- 
737
     1  1               --5--           
     2          2               --5--   
     3          3               --5--   
   738          738               --5-- 
738

И вот оно - просто, эффективно и потоковое.