Почему использование цикла оболочки для обработки текста считается плохой практикой?

Является ли использование цикла while для обработки текста вообще плохой практикой в ​​оболочках POSIX?

Как отметил Стефан Шазелас , некоторые из причин, по которым не используется оболочка, - это концептуальность , надежность , удобочитаемость , производительность и безопасность .

Этот ответ объясняет аспекты надежности и удобочитаемости :

while IFS= read -r line <&3; do
  printf '%s\n' "$line"
done 3< "$InputFile"

Для исполнения , то whileцикл и чтения являются чрезвычайно медленно при чтении из файла или труб, так как для чтения оболочки встроенных читает один символ за один раз.

Как насчет концептуальных аспектов и аспектов безопасности ?

Да, мы видим ряд вещей, таких как:

while read line; do
  echo $line | cut -c3
done

Или хуже:

for line in `cat file`; do
  foo=`echo $line | awk '{print $2}'`
  echo whatever $foo
done

(не смейся, я видел много таких).

Как правило, от начинающих сценариев оболочки. Это наивные буквальные переводы того, что вы делаете в императивных языках, таких как C или python, но это не то, как вы делаете вещи в оболочках, и эти примеры очень неэффективны, абсолютно ненадежны (потенциально могут привести к проблемам безопасности), и если вам когда-нибудь удастся чтобы исправить большинство ошибок, ваш код становится неразборчивым.

Концептуально

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

Оболочки - это язык более высокого уровня. Можно сказать, что это даже не язык. Они раньше всех интерпретаторов командной строки. Работа выполняется теми командами, которые вы запускаете, а оболочка предназначена только для их управления.

Одной из замечательных вещей, которые представил Unix, был канал и те потоки по умолчанию stdin / stdout / stderr, которые все команды обрабатывают по умолчанию.

За 45 лет мы не нашли лучше, чем этот API, чтобы использовать всю мощь команд и заставить их взаимодействовать для выполнения какой-либо задачи. Вероятно, это основная причина, по которой люди до сих пор используют снаряды.

У вас есть режущий инструмент и инструмент для транслитерации, и вы можете просто сделать:

cut -c4-5 < in | tr a b > out

Оболочка просто выполняет сантехнику (открывает файлы, настраивает каналы, вызывает команды), и когда все готово, она просто течет, а оболочка ничего не делает. Инструменты выполняют свою работу одновременно, эффективно в своем собственном темпе с достаточной буферизацией, чтобы не блокировать один другой, а просто красиво и в то же время так просто.

Однако вызов инструмента имеет свою стоимость (и мы разработаем ее с точки зрения производительности). Эти инструменты могут быть написаны с тысячами инструкций на языке C. Необходимо создать процесс, инструмент должен быть загружен, инициализирован, затем очищен, процесс уничтожен и ожидается.

Вызывать cutэто как открыть кухонный ящик, взять нож, использовать его, помыть, высушить, положить обратно в ящик. Когда вы делаете:

while read line; do
  echo $line | cut -c3
done < file

Это как для каждой строки файла: взять readинструмент из кухонного ящика (очень неуклюжий, потому что он не предназначен для этого ), прочитать строку, вымыть инструмент для чтения, положить его обратно в ящик. Затем запланируйте встречу для инструмента echoи cutинструмента, достаньте их из ящика, вызовите их, вымойте их, высушите их, положите обратно в ящик и так далее.

Некоторые из этих инструментов ( readи echo) построены в большинстве оболочек, но это вряд ли имеет значение здесь , так echoи по- cutпрежнему должны быть запущены в отдельных процессах.

Это как разрезать лук, но помыть нож и положить его обратно в кухонный ящик между каждым кусочком.

Здесь очевидный способ - достать cutинструмент из ящика, нарезать весь лук и положить его в ящик после того, как вся работа будет выполнена.

Таким образом, в оболочках, особенно для обработки текста, вы вызываете как можно меньше утилит и заставляете их взаимодействовать с задачей, а не запускаете тысячи инструментов подряд, ожидая, пока каждый из них запустится, запустится, очистится перед запуском следующей.

Дальнейшее чтение в ответ Брюса . Низкоуровневые внутренние инструменты обработки текста в оболочках (за исключением, может быть, для zsh) ограничены, громоздки и, как правило, не подходят для общей обработки текста.

Представление

Как было сказано ранее, запуск одной команды имеет свою стоимость. Огромная стоимость, если эта команда не встроена, но даже если она встроена, цена велика.

И оболочки не предназначены для такой работы, они не претендуют на то, чтобы быть эффективными языками программирования. Это не просто интерпретаторы командной строки. Таким образом, небольшая оптимизация была сделана на этом фронте.

Также оболочки запускают команды в отдельных процессах. Эти строительные блоки не разделяют общую память или состояние. Когда вы делаете a fgets()или fputs()в C, это функция в stdio. stdio сохраняет внутренние буферы для ввода и вывода для всех функций stdio, чтобы избежать слишком частых системных вызовов.

Соответствующие даже встроенные утилиты оболочки ( read, echo, printf) не может сделать это. readпредназначен для чтения одной строки. Если он читает после символа новой строки, это означает, что следующая команда, которую вы запустите, пропустит его. Поэтому readприходится читать входные данные по одному байту за раз (некоторые реализации имеют оптимизацию, если входные данные представляют собой обычный файл, поскольку они читают фрагменты и выполняют поиск назад, но это работает только для обычных файлов и, bashнапример, читает только 128-байтовые фрагменты, что все еще намного меньше чем текстовые утилиты сделают).

То же самое на стороне вывода, echoне может просто буферизовать свой вывод, он должен выводить его сразу, потому что следующая команда, которую вы выполняете, не будет использовать этот буфер.

Очевидно, что последовательное выполнение команд означает, что вы должны их ждать, это небольшой танец планировщика, который дает контроль над оболочкой, инструментами и обратно. Это также означает (в отличие от использования долго работающих экземпляров инструментов в конвейере), что вы не можете использовать несколько процессоров одновременно, когда они доступны.

Между этим while readциклом и (предположительно) эквивалентом cut -c3 < file, в моем быстром тесте, в моих тестах соотношение времени процессора составляет около 40000 (одна секунда против полдня). Но даже если вы используете только встроенные функции оболочки:

while read line; do
  echo ${line:2:1}
done

(здесь с bash), это все еще около 1: 600 (одна секунда против 10 минут).

Надежность / разборчивость

Очень трудно правильно понять этот код. Примеры, которые я привел, слишком часто встречаются в дикой природе, но в них много ошибок.

readэто удобный инструмент, который может делать много разных вещей. Он может читать ввод от пользователя, разбивать его на слова для хранения в различных переменных. read lineвовсе не читать строку ввода, или , может быть , он читает строку в совершенно особым образом. На самом деле он читает слова из входных данных, разделенных этими словами, $IFSи где обратную косую черту можно использовать для экранирования или символов новой строки.

Со значением по умолчанию $IFS, на входе, как:

   foo\/bar \
baz
biz

read lineбудет хранить "foo/bar baz"в $lineне , " foo\/bar \"как вы ожидали бы.

Чтобы прочитать строку, вам действительно нужно:

IFS= read -r line

Это не очень интуитивно понятно, но так оно и есть, помните, что оболочки не предназначены для такого использования.

То же самое для echo. echoрасширяет последовательности. Вы не можете использовать его для произвольного содержимого, такого как содержимое случайного файла. Вам нужно printfздесь вместо этого.

И, конечно, есть типичное забывание процитировать вашу переменную, в которую все попадают. Итак, это больше:

while IFS= read -r line; do
  printf '%s\n' "$line" | cut -c3
done < file

Теперь еще несколько предостережений:

• за исключением того zsh, что это не работает, если ввод содержит символы NUL, в то время как по крайней мере текстовые утилиты GNU не будут иметь проблемы.
• если после последней новой строки есть данные, они будут пропущены
• внутри цикла stdin перенаправляется, поэтому вам следует обратить внимание на то, что команды в нем не читаются из stdin.
• для команд внутри циклов мы не обращаем внимания на то, будут ли они успешными или нет. Обычно условия ошибок (переполнение диска, ошибки чтения ...) обрабатываются плохо, обычно хуже, чем при правильном эквиваленте.

Если мы хотим решить некоторые из этих проблем выше, это становится:

while IFS= read -r line <&3; do
  {
    printf '%s\n' "$line" | cut -c3 || exit
  } 3<&-
done 3< file
if [ -n "$line" ]; then
    printf '%s' "$line" | cut -c3 || exit
fi

Это становится все менее и менее разборчивым.

Существует ряд других проблем с передачей данных командам через аргументы или извлечением их выходных данных в переменных:

• ограничение на размер аргументов (некоторые реализации текстовых утилит также имеют ограничение, хотя эффект от достигаемых обычно менее проблематичен)
• символ NUL (также проблема с текстовыми утилитами).
• аргументы принимаются как варианты, когда они начинаются -(или +иногда)
• различные причуды различных команд, обычно используемых в этих циклах, как expr, test...
• (ограниченные) операторы манипулирования текстом различных оболочек, которые обрабатывают многобайтовые символы противоречивыми способами.
• ...

Соображения безопасности

Когда вы начинаете работать с переменными оболочки и аргументами команд , вы входите в минное поле.

Если вы забыли заключить в кавычки свои переменные , забыли маркер конца опции , работали в локалях с многобайтовыми символами (норма в наши дни), вы наверняка внесете ошибки, которые рано или поздно станут уязвимыми.

Когда вы можете использовать петли.

TBD

Что касается концептуальности и разборчивости, оболочки обычно интересуются файлами. Их «адресуемая единица» - это файл, а «адрес» - это имя файла. Оболочки имеют все виды методов тестирования на существование файла, тип файла, форматирование имени файла (начиная с подстановки). У оболочек очень мало примитивов для работы с содержимым файлов. Программисты оболочки должны вызывать другую программу для работы с содержимым файла.

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

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

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

Для первых частей ( initialization) обычно не имеет значения, что команды оболочки медленные - это всего лишь несколько десятков команд, возможно, с несколькими короткими циклами. Даже если мы напишем эту часть неэффективно, обычно для инициализации потребуется меньше секунды, и это нормально - это происходит только один раз.

Но когда мы приступаем к обработке большого файла, в котором могут быть тысячи или миллионы строк, для сценария оболочки не подходит длительная доля секунды (даже если это всего несколько десятков миллисекунд) для каждой строки, как это может сложить до нескольких часов.

Именно тогда нам нужно использовать другие инструменты, и прелесть сценариев оболочки Unix в том, что они делают это очень простым для нас.

Вместо того, чтобы использовать цикл для просмотра каждой строки, нам нужно пропустить весь файл через конвейер команд . Это означает, что вместо того, чтобы вызывать команды тысячи или миллионы раз, оболочка вызывает их только один раз. Это правда, что эти команды будут иметь циклы для построчной обработки файла, но они не являются сценариями оболочки и предназначены для быстрой и эффективной работы.

В Unix есть много замечательных встроенных инструментов, от простых до сложных, которые мы можем использовать для создания наших конвейеров. Я обычно начинаю с простых и использую только более сложные, когда это необходимо.

Я также попытался бы придерживаться стандартных инструментов, доступных на большинстве систем, и стараться, чтобы мое использование было переносимым, хотя это не всегда возможно. И если ваш любимый язык Python или Ruby, возможно, вы не будете возражать против дополнительных усилий, чтобы убедиться, что он установлен на каждой платформе, на которой должно работать ваше программное обеспечение :-)

Простые инструменты включают в себя head, tail, grep, sort, cut, tr, sed, join(при слиянии 2 файлов), и awkостроты, среди многих других. Удивительно, что некоторые люди могут делать с сопоставлением с шаблоном и sedкомандами.

Когда это становится более сложным, и вам действительно нужно применить некоторую логику к каждой строке, awkхороший вариант - либо однострочный (некоторые люди помещают целые сценарии awk в «одну строку», хотя это не очень удобно для чтения), либо в короткий внешний скрипт.

Как awkи интерпретируемый язык (например, ваша оболочка), удивительно, что он может выполнять построчную обработку так эффективно, но он специально создан для этого и действительно очень быстр.

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

И наконец, есть старый добрый C, если вам нужна максимальная скорость и высокая гибкость (хотя обработка текста немного утомительна). Но это, вероятно, очень плохое использование вашего времени для написания новой C-программы для каждой задачи обработки файлов, с которой вы сталкиваетесь. Я много работаю с CSV-файлами, поэтому я написал несколько универсальных утилит на C, которые я могу использовать во многих различных проектах. По сути, это расширяет диапазон «простых, быстрых инструментов Unix», которые я могу вызывать из своих сценариев оболочки, так что я могу обрабатывать большинство проектов только за счет написания сценариев, что намного быстрее, чем написание и отладка кода C на каждый раз!

Некоторые последние подсказки:

• не забудьте запустить свой основной сценарий оболочки export LANG=C, иначе многие инструменты будут обрабатывать ваши обычные ASCII-файлы как Unicode, делая их намного медленнее
• Также подумайте о настройке, export LC_ALL=Cесли вы хотите sortпроизводить последовательный порядок, независимо от среды!
• если вам нужны sortваши данные, это, вероятно, займет больше времени (и ресурсов: процессор, память, диск), чем все остальное, поэтому постарайтесь свести к минимуму количество sortкоманд и размер файлов, которые они сортируют
• один конвейер, когда это возможно, обычно наиболее эффективен - последовательный запуск нескольких конвейеров с промежуточными файлами может быть более читабельным и отладочным, но увеличит время, необходимое вашей программе

Да, но...

Правильный ответ Stéphane Chazelas основан на оболочку концепции делегирования каждый текст работы в конкретные бинарные файлы, как grep, awk, sedи другие.

Поскольку bash способен на многое, он сам может сбросить вилки (даже чем запускать другого переводчика для выполнения всей работы).

Для примера, посмотрите на этот пост:

https://stackoverflow.com/a/38790442/1765658

а также

https://stackoverflow.com/a/7180078/1765658

проверить и сравнить ...

Конечно

Там нет соображений о вводе пользователя и безопасности !

Не пишите веб-приложение под Bash !

Но для многих задач администрирования сервера, где Баш может быть использован вместо оболочки , используя встроенные функции Баша может быть очень эффективными.

Мой смысл:

Написание таких инструментов, как bin utils , не такая же работа, как системное администрирование.

Так что не такие же люди!

Где системные администраторы должны знать shell, они могут писать прототипы , используя его предпочтительный (и самый известный) инструмент.

Если эта новая утилита (прототип) действительно полезна, некоторые другие люди могут разработать специальный инструмент, используя более подходящий язык.