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

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

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

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

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

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

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

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

Без разницы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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