Почему бы мне не «сделать ставку на будущее компании» на сценарии оболочки?

Я смотрел http://tldp.org/LDP/abs/html/why-shell.html и был поражен:

Когда не следует использовать сценарии оболочки

...

  • Критически важные приложения, на которые вы делаете ставку на будущее компании

Почему нет?

Ответов (9)

Решение

Использование сценариев оболочки - это нормально, если вы используете их сильные стороны. В моей компании есть программные переключатели класса 5, а код обработки вызовов и интерфейс подготовки написаны на java. Все остальное написано на KSH - дампы БД для резервных копий, обрезки, ротации файлов журналов и всей автоматической отчетности. Я бы сказал, что все эти вспомогательные функции, хотя и не имеют прямого отношения к пути вызова, критически важны. Особенно взаимодействие с БД. Если что-то пойдет не так с кодом взаимодействия с БД и будут сброшены таблицы маршрутизации вызовов, это может вывести нас из бизнеса.

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

Держу пари, что автор показывает, что им неудобны некоторые аспекты качественного написания сценариев оболочки. Кто юнит-тестирует скрипты BASH например.

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

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

Как и некоторые другие люди, говорят, что язык - это фактор. Я полностью доверяю своим сценариям оболочки и полагаюсь на свои короткие шаги, которые я не хочу запоминать, и склеивающие программы. Это не означает, что я собираюсь создать веб-сайт, на котором будет работать bash на бэкэнде, но я обязательно буду использовать bash / ksh / python / something, чтобы помочь мне создать скелетный проект и управлять моей упаковкой и развертыванием.

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

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

Что бы ни.

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

Хороший код - это хорошо, а плохой код - это плохо - независимо от того, написан ли он как сценарий Bash, файл Windows CMD, на Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol или на скомпилированном C.

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

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

Например, я видел (и написал) несколько сценариев ksh, которые взаимодействуют с базой данных Oracle с помощью SQL * Plus. К сожалению, система не могла правильно масштабироваться, потому что в запросах не использовались переменные связывания. Ударьте по сценариям оболочки, верно? Неправильный. Проблема была не в сценариях оболочки, а в SQL * Plus. Фактически, проблема производительности исчезла, когда я заменил SQL * Plus скриптом Perl, который подключался к базе данных и использовал переменные связывания.

Я легко могу представить, что использование сценариев оболочки в программном обеспечении для полета космического корабля было бы плохой идеей. Но Java или C++ могут быть одинаково плохим выбором. Лучшим выбором будет любой язык (ассемблер?), Который обычно используется для этой цели.

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

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

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

Сценарии не подходят для реализации некоторых критически важных функций, поскольку для работы они должны иметь разрешения + r и + x. Исполняемые файлы должны иметь только + x.

Тот факт, что в сценарии есть + r, означает, что пользователи могут сделать копию сценария, отредактировать / подорвать его и выполнить свою отредактированную версию Cuckoo's-Egg.

Когда я читаю эту цитату, я сосредотачиваюсь на приложениях », а не на «критически важной» части.

Я прочитал это так, будто bash не предназначен для написания приложений, а для написания сценариев. Конечно, ваше приложение может иметь несколько служебных сценариев, но не стоит писать, critical-business-logic.sh потому что другой язык, вероятно, лучше для подобных вещей.