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

Unix имеет очень сильную конструктивную позицию, «философию инструментов» - делайте что-то один раз & хорошо, предоставляйте простой универсальный интерфейс (stdin + stdout), все (почти) является файлом файлы просты: строки байтов или строки текста и делают использование инструментов простым, легким и очевидным - эта модель поддерживает быстрое прототипирование, повторное использование, рефакторинг / улучшение (опубликованные интерфейсы инструментов неизменны, а реализации могут быть улучшены).

Это противоположность N.I.H. - Not Invented Here (строите все сами) vs Stand on the Shoulders of Giants.

Я пишу на языке Borne или «bash» по исторической случайности. Набор инструментов PWB - вырезать, объединить, вставить, grep, sort, sed, awk - все заменены и улучшены в Perl 5, но я более плавно и быстрее использую эти инструменты. Достопочтенный rcs для управления версиями не имеет эквивалента в Perl. make, ключевой компонент PWB, редко используется ни в оболочке, ни в сценариях Perl.

Инструменты PWB хорошо работают для создания прототипов и задач администрирования и хорошо масштабируются на одной машине или через SSH на несколько машин.

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

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

Мне нужна версия grep (сопоставление строк), которая имеет два выходных потока, совпадающие строки и все остальное, чтобы конвейеры могли обрабатывать эфемерные данные без сохранения и повторной обработки промежуточных файлы. Примитивы Unix pipe / fork / dup могут работать с несколькими потоками, и я видел интересные версии наборов инструментов, которые делают более 1: 1, но оболочка и все существующие инструменты предполагают один вход, один выход. транслировать. Как может линейная командная строка описывать нелинейные потоки? Это возможно, если добавить много сложностей.

Сценарии администрирования могут быть очень большими и обычно эффективно выполняют большие важные вычислительные задачи, но баг всегда «Неизвестные неизвестные» - условия ошибки, сбоя или отказа, такие как мой 'dd' EOF, которые либо инструменты не замечают, либо ловят. & report, или скрипту не удается отловить или проверить.

Один 10-летний + I.T. однажды профессионал сказал: «Не беспокойтесь об ошибках», от чего я потерял дар речи и на который в то время у меня не было заранее подготовленного ответа.

Теперь я бы сказал:

  • потому что это важно, и
  • Я бы предпочел потратить немного времени и денег сейчас на предотвращение проблем, чем много времени и денег на устранение нескольких важных деловых событий позже.
    Разработчики проекта сетуют: Есть никогда не бывает времени делать это правильно с первого раза, но всегда время делать это снова и снова.

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

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

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

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

Оболочки Unix чрезвычайно эффективны, надежны и лаконичны для тех задач, в которых они хороши, гораздо больше, чем любой другой язык сценариев, который я видел: Perl, Python и другие.

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

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

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

Следует ли мне или любому работающему администратору отказаться от написания сценариев оболочки (или PowerShell)?
Абсолютно нет. Это небольшая, простая и мощная парадигма, в большинстве своем очень хорошо подходящая для решаемых задач и проверенная на практике.
Их используют, потому что они работают.

Следует ли использовать сценарии для создания прототипов небольших проектов с использованием оболочки, стандартных инструментов и конвейеров?
Совершенно верно. Но не забывайте, что прототип - это не инструмент производства. Если он регулярно используется, особенно «другими», он заслуживает того, чтобы его правильно спроектировали и построили, даже если на языке сценариев более высокого уровня, таком как Python.

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

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

  • почтенная оболочка Unix примерно 1969 года и ее набор инструментов нуждаются в формальном пересмотре и переработке, чтобы соответствовать полувековым достижениям в области системных технологий и их использования. Возможно, инструменты должны быть динамическими библиотеками? Как писать скрипты с множеством потоков? Достаточно ли простого текстового файла + редактора?
  • Переосмысление оболочки может быть хорошим временем для обзора и стандартизации всего стандартного набора инструментов и их опций / интерфейсов. Требуется обратная совместимость - должно быть нулевые барьеры для входа, чтобы можно было использовать что-либо новое. Зачем тратить силы, если нет никаких шансов, что новое дело возьмут в руки?
  • Не существует простого, упорядоченного и автоматизированного решения для перехода от прототипа сценария оболочки к любому языку более низкого уровня.
    Perl 5 решил эту проблему с помощью 's2p' и 'a2p' - sed в perl и awk в perl.
    Если администраторы-программисты не могут тривиально перенести сценарии оболочки на

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

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