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

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

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

...

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

Почему бы и нет?

19.08.2008 23:50:47
9 ОТВЕТОВ
РЕШЕНИЕ

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

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

14
20.08.2008 03:12:01

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

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

0
19.08.2008 23:58:32
Большинство языков связаны с ОС в большинстве случаев.
Jé Queue 16.03.2012 02:08:39

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

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

6
20.08.2008 00:17:20

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

Без разницы.

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

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

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

5
20.08.2008 00:37:34

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

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

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

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

5
20.08.2008 00:33:25

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

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

2
20.08.2008 02:46:48

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

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

-2
18.09.2008 11:54:25
Так что, если они могут выполнить скопированный сценарий оболочки? Если пользователь может создать файл и выполнить его, то не имеет значения, скопировал ли пользователь файл или записал его с нуля: исполняемый файл в любом случае обладает теми же возможностями.
Max Nanasy 31.12.2012 20:52:11

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

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

2
18.09.2008 13:00:17

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

0
28.09.2019 19:43:16