Почему я не должен “ставить будущее компании” на shell-скрипты?[закрыто]
https://stackoverflow.com/questions/17231
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я смотрел на http://tldp.org/LDP/abs/html/why-shell.html и был поражен:
Когда не следует использовать сценарии оболочки
...
- Критически важные приложения, на которые вы делаете ставку в будущем компании
Почему бы и нет?
Решение
Использование shell-скриптов прекрасно, когда вы используете их сильные стороны.В моей компании есть несколько программных переключателей класса 5, а код обработки вызовов и интерфейс подготовки написаны на java.Все остальное записано в дампах KSH - DB для резервного копирования, обрезки, ротации файлов журнала и всей автоматической отчетности.Я бы сказал, что все эти функции поддержки, хотя и не имеют прямого отношения к пути вызова, являются критически важными.Особенно взаимодействие с базой данных.Если бы что-то пошло не так с кодом взаимодействия с базой данных и сбросили таблицы маршрутизации вызовов, это могло бы вывести нас из бизнеса.
Но ничто никогда не идет наперекосяк, потому что shell-скрипты - идеальный язык для подобных вещей.Они небольшие, их хорошо понимают, манипулирование файлами - их сильная сторона, и они стабильны.Не похоже, что KSH09 будет полностью переписан, потому что кто-то думает, что он должен компилироваться в байтовый код, так что это стабильный интерфейс.Честно говоря, интерфейс подготовки, написанный на Java, довольно часто выходит из строя, а сценарии оболочки, насколько я помню, никогда не давали сбоев.
Другие советы
Я вроде как думаю, что в статье приведен действительно хороший список причин, по которым не следует использовать shell-скрипты - при этом единственный критический маркер, на который вы указываете, является скорее выводом, основанным на всех остальных маркерах.
С учетом сказанного, я думаю, причина, по которой вы не хотите создавать критически важное приложение на основе сценария оболочки, заключается в том, что даже если ни один из других маркерных пунктов не применяется Сегодня, любое приложение, которое будет поддерживаться в течение определенного периода времени, будет эволюционировать вплоть до того, что в какой-то момент вы столкнетесь по крайней мере с одной из этих потенциальных ловушек ..... и вы действительно ничего не сможете с этим поделать, если не будете полностью переделывать, чтобы придумать исправление .... жаль, что вы с самого начала не использовали что-то более мощное в промышленном плане.
Очевидно, что для меня это своего рода соломенный человечек, которого можно сбить с ног.Мне действительно интересно, почему люди считают, что сценариев оболочки следует избегать в "критически важных приложениях", но я не могу придумать убедительной причины.
Например, я видел (и написал) несколько ksh-скриптов, которые взаимодействуют с базой данных Oracle с использованием SQL * Plus.К сожалению, система не смогла должным образом масштабироваться, потому что запросы не использовали переменные привязки.Нанесите первый удар по шелл-скриптам, верно?Неправильно.Проблема была не в сценариях оболочки, а в SQL * Plus.фактически, проблема с производительностью исчезла, когда я заменил SQL * Plus скриптом Perl, который подключался к базе данных и использовал переменные bind.
Я легко могу себе представить, что использование сценариев оболочки в программном обеспечении полета космического корабля было бы плохой идеей.Но Java или C ++ могут быть столь же плохим выбором.Лучшим выбором был бы любой язык (ассемблер?), который обычно используется для этой цели.
Дело в том, что если вы используете какую-либо разновидность Unix, вы используете сценарии оболочки в критически важных ситуациях, предполагая, что вы считаете загрузку критически важной.Когда скрипту нужно сделать что-то, в чем shell не особенно хороша, вы помещаете эту часть в подпрограмму.Вы не выбрасываете сценарий оптом.
Скрипты - это не что иное, как компьютерные программы.Кто-то может возразить, что скрипты менее сложны.Те же самые люди обычно признают, что вы можете писать сложный код на скриптовых языках, но что эти скрипты на самом деле уже не скрипты, а полноценные программы по определению.
Неважно.
Правильный ответ, на мой взгляд, - "это зависит".Что, кстати, является тем же самым ответом на обратный вопрос о том, следует ли вам доверять скомпилированным исполняемым файлам для критически важных приложений.
Хороший код - это хорошо, а плохой код - это плохо, написан ли он в виде Bash-скрипта, CMD-файла Windows, на Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol или скомпилированного C.
Который является нет сказать, что выбор языка не имеет значения. Иногда существуют очень веские причины для выбора определенного языка или для компиляции по сравнению синтерпретация (производительность, масштабируемость, возможности, безопасность и т.д.).Но, при прочих равных условиях, я бы доверил shell-скрипту, написанному великим программистом, вместо эквивалентной программы на C ++, написанной придурком, в любой день недели.
Вероятно, это шелл-скрипты, которые помогают управлять компанией в будущее.Я знаю только с точки зрения программирования, что я бы потратил много времени на выполнение повторяющихся задач, которые я делегировал сценариям оболочки.Например, я знаю большинство команд subversion для командной строки, но если я смогу объединить все эти команды в один скрипт, который я смогу запускать по своему желанию, я сэкономлю время и умственную энергию.
Как уже говорили несколько других людей, язык - это важный фактор.В своих коротких "не хочу запоминать шаги" и программах склеивания я полностью доверяю своим скриптам оболочки и полагаюсь на них.Это не значит, что я собираюсь создавать веб-сайт, который запускает bash на серверной части, но я обязательно буду использовать bash / ksh / python / что угодно, чтобы помочь мне сгенерировать скелет проекта и управлять моей упаковкой и развертыванием.
Когда я читаю эту цитату, я сосредотачиваюсь на "приложения- часть, а не "критически важная" часть.
Я прочитал это как утверждение, что bash предназначен не для написания приложений, а для, ну, написания сценариев.Так что, конечно, в вашем приложении могут быть какие-то сценарии ведения домашнего хозяйства, но не начинайте писать critical-business-logic.sh потому что другой язык, вероятно, лучше подходит для подобных вещей.
Я бы поспорил, что автор показывает, что им неудобны некоторые аспекты качественного написания сценариев wrt shell.Например, модуль Who тестирует BASH-скрипты.
Кроме того, скрипты довольно сильно связаны с базовой операционной системой, что может быть чем-то негативным.
Неважно, что всем нам нужен гибкий инструмент для взаимодействия с операционной системой.Это понятное человеку взаимодействие с операционной системой, которое мы используем, это все равно что использовать отвертку с винтами.Командная строка всегда будет инструментом, который нам нужен либо для администратора, программиста, либо для сети .Посмотрите на окно, которое они даже расширили в своем powershell.
Скрипты не подходят для реализации определенных критически важных функций, поскольку для работы они должны иметь разрешения +r и + x.Исполняемые файлы должны иметь только +x .
Тот факт, что скрипт имеет +r , означает, что пользователи могут создать копию скрипта, отредактировать / подорвать его и выполнить свою отредактированную версию Cuckoo's Egg .
