Почему я не должен "bet the future of the company" на shell скриптах?

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

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

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

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

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

Что угодно.

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

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

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

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

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

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

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

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

Как и некоторые другие люди, которые говорят, что язык-это фактор. Для моих коротких шагов don ' t-want-to-remember и программ клея я полностью доверяю своим сценариям shell и полагаюсь на них. Это не означает, что я собираюсь создать веб-сайт, который будет работать с bash на бэкэнде, но я обязательно использую bash/ksh/python/whatever, чтобы помочь мне создать проект скелета и управлять моей упаковкой и deployment.

Когда я читаю эту цитату, я сосредотачиваюсь на части "приложения", а не на части "mission critical".

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

Держу пари, что автор показывает, что они испытывают дискомфорт с некоторыми аспектами написания сценариев qualtiy wrt shell. Например, модульные тесты ВОЗ BASH скриптов.

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

Независимо от того, что мы все neec fexible инструмент для взаимодействия с ОС. Это читаемое человеком взаимодействие с ОС, которое мы используем, это похоже на использование отвертки с винтами. Командная строка всегда будет atool нам нужен либо администратор, программист или сеть . Посмотрите на окно, которое они даже расширили на своем powershell.

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

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