скрипты на все случаи жизни

Что такое скрипт

Общее понимание скрипта

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

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

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

История появления скриптов

Для общего развития предлагаю немного окунуться в историю появления скриптов и взглянуть на то, какими они были раньше. Начали применять их под управлением семейства операционных систем Unix еще 50 лет назад. Одной из первых командных оболочек была sh, в ней использовались shell scripts, которые позволяли выполнять самые разнообразные задачи на компьютере.

Ниже вы видите небольшой код, предназначенный для конвертирования изображения из JPG в PNG:

Обозначения после знаков # являются комментариями и не относятся к скрипту, они только описывают для пользователя действия. Этот пример был взят из открытой библиотеки и отлично показывает, что всего несколько строк кода позволяют обработать изображение, сменив его формат на другой. Сейчас скрипты могут быть более массивными и выполнять задачи на уровень сложнее.

Сферы использования скриптов

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

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

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

Если говорить о Windows, то в ней вы можете найти встроенный инструмент CMD (PowerShell), который и предназначен для запуска скриптов, хранящихся в формате BAT.

Самостоятельное написание и применение скриптов

Разберем самостоятельное написание и применение скриптов на примере Windows. Допустим, у вас стоит задача проверить стабильность соединения с конкретным сайтом без запуска браузера. Для этого есть одна полезная команда, запускаемая через Командную строку. А если нужно еще сформировать и отчет о результатах проверки, не совсем удобно будет вводить несколько разных команд по очереди, особенно в тех случаях, когда задача выполняется раз в несколько дней или чаще. Тогда создается BAT-файл с таким содержимым:

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

Источник

Bash-скрипты, часть 10: практические примеры

В предыдущих материалах мы обсуждали различные аспекты разработки bash-скриптов, говорили о полезных инструментах, но до сих пор рассматривали лишь небольшие фрагменты кода. Пришло время более масштабных проектов. А именно, здесь вы найдёте два примера. Первый — скрипт для отправки сообщений, второй пример — скрипт, выводящий сведения об использовании дискового пространства.

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

Отправка сообщений в терминал пользователя

Как видите, задача: «отправить сообщение», при ближайшем рассмотрении, оказалась задачей: «проверить возможность отправки сообщения, и, если нет препятствий, отправить его». Займёмся решением задачи, то есть — разработкой bash-скрипта.

▍Команды who и mesg

Ядром скрипта являются несколько команд, которые мы ещё не обсуждали. Всё остальное должно быть вам знакомо по предыдущим материалам.

Результаты вызова команды who

В данном случае команда вывела «is y», это значит, что пользователь, под которым мы работаем в системе, может принимать сообщения, отправленные в его терминал. В противном случае mesg выведет «is n».

При этом проверка возможна только для пользователей, которые вошли в систему. Если такая команда, после имени пользователя, выведет чёрточку (-), это означает, что пользователь запретил запись в свой терминал, то есть, сообщения ему отправлять нельзя. О том, что пользователю можно отправлять сообщения, говорит знак «плюс» (+).

Если у вас приём сообщений отключён, а вы хотите позволить другим пользователям отправлять вам сообщения, можно воспользоваться такой командой:

Включение приёма сообщений от других пользователей

После включения приёма сообщений mesg возвращает «is y».
Конечно, для обмена сообщениями нужны два пользователя, поэтому мы, после обычного входа в систему, подключились к компьютеру по ssh. Теперь можно поэкспериментировать.

▍Команда write

Обратите внимание на то, что с помощью write можно отправлять сообщения пользователям, вошедшим в виртуальную консоль. Пользователи, которые работают в графическом окружении (KDE, Gnome, Cinnamon, и так далее), не могут получать подобные сообщения.

Проверка возможности отправки сообщений и отправка сообщения

Вот что увидит в своём терминале пользователь, которому мы отправили сообщение.

Новое сообщение, пришедшее в терминал

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

▍Создание скрипта для отправки сообщений

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

Проверка статуса пользователя

▍Проверка возможности записи в терминал пользователя

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

Проверка возможности отправки сообщений пользователю

▍Проверка правильности вызова скрипта

Первым параметром скрипта является имя пользователя, которому мы хотим отправить сообщение. Вторым — текст сообщения, в данном случае — состоящий из одного слова. Для того, чтобы проверить, передано ли скрипту сообщение для отправки, воспользуемся таким кодом:

Проверка параметров командной строки, указанных при вызове скрипта

Тут, если при вызове скрипта ему не было передано сообщение для отправки, мы сообщаем об этом и завершаем работу. В противном случае — идём дальше.

▍Получение сведений о терминале пользователя

Прежде чем отправить пользователю сообщение, нужно получить сведения о терминале, в котором он работает и сохранить имя терминала в переменной. Делается это так:

Теперь, после того, как все необходимые данные собраны, осталось лишь отправить сообщение:

Вызов готового скрипта выглядит так:

Успешная отправка сообщения с помощью bash-скрипта

Как видно, всё работает как надо. Однако, с помощью такого сценария можно отправлять лишь сообщения, состоящие из одного слова. Хорошо бы получить возможность отправлять более длинные сообщения.

▍Отправка длинных сообщений

Попытка отправки длинного сообщения

Вот полный текст сценария:

Успешная отправка длинного сообщения:

Длинное сообщение успешно дошло до адресата. Теперь рассмотрим следующий пример.

Скрипт для мониторинга дискового пространства

Отсортированный список объектов

В начале строки выводится её номер, потом идёт двоеточие и знак табуляции, далее — объём дискового пространства, следом — ещё один знак табуляции и имя папки.

Соберём вместе всё то, о чём мы говорили:

Вывод сведений о дисковом пространстве

Для того, чтобы повысить эффективность работы скрипта, код которого вы совсем скоро увидите, реализуем возможность получения данных сразу по нескольким директориям. Для этого создадим переменную MY_DIRECTORIES и внесём в неё список интересующих нас директорий:

Переберём список с помощью цикла for и вызовем вышеописанную последовательность команд для каждого элемента списка. Вот что получилось в результате:

Получение сведений о нескольких директориях

Итоги

На сегодня это всё. В следующий раз поговорим об автоматизации работы с интерактивными утилитами с помощью expect.

Уважаемые читатели! Есть ли у вас на примете несложные (а может быть и сложные, но понятные) bash-скрипты, разбор которых будет полезен новичкам?

Источник

В любой непонятной ситуации — пиши скрипты

Скрипты — один из самых распространенных способов сделать приложение более гибким, с возможностью поправить что-то прямо на ходу. Конечно же, у этого подхода есть и недостатки, нужно всегда помнить про баланс между гибкостью и управляемостью. Но в этой статье мы не будем рассуждать “в общем” по поводу плюсов и минусов использования скриптов, мы рассмотрим практические способы реализации этого подхода, а также представим библиотеку, которая предоставляет удобную инфраструктуру для добавления скриптов в приложения, написанные на Spring Framework.

Несколько вводных слов

Когда хочется добавить возможность менять бизнес-логику в приложении без перекомпиляции и последующего развертывания, то скрипты — один из способов, который приходит на ум в первую очередь. Зачастую, скрипты появляются не потому что так было задумано, а потому что так получилось. Например, в спецификации есть часть логики, которая вот прямо сейчас не до конца ясна, но, чтобы не тратить лишние пару дней (а иногда и дольше) на анализ, можно сделать точку расширения и вызывать скрипт — заглушку. А потом, конечно, этот скрипт будет переписан, когда требования прояснятся.

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

Те приемы, которые будут рассмотрены далее, могут быть полезны как разработчикам, которые уже используют скрипты в своем приложении, так и тем, кто только думает об этом.

Ничего личного, только скриптинг

С JSR-233 скриптинг в Java стал очень простым. Существует достаточное количество скриптовых движков, основанных на этом API (Nashorn, JRuby, Jython и ещё некоторые), так что добавить немного скриптовой магии в код — не проблема:

Очевидно, что, если такой код будет раскидан по всему приложению, то оно превратится непонятно во что. И, безусловно, если у вас в приложении больше одного вызова скрипта, то нужно делать отдельный класс для работы с ними. Иногда можно пойти ещё дальше и сделать специальные классы, которые будут оборачивать вызовы evaluateGroovy() в обычные типизированные Java методы. В этих методах будет довольно однотипный служебный код, как в примере:

Такой подход сильно увеличивает прозрачность при вызовах скриптов из кода приложения — сразу видно, какие параметры скрипт принимает, какого они типа и что возвращается. Главное — не забыть добавить в стандарты написания кода запрет на вызов скриптов не из типизированных методов!

Прокачиваем скрипты

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

Например, в CUBA был сделан довольно хитроумный движок для скриптинга, который поддерживает дополнительные возможности, такие как:

И было бы несправедливо не упомянуть GraalVM — экспериментальный движок, который умеет выполнять программы на разных языках (JVM и не-JVM) и позволяет вставлять в Java приложения модули на этих языках. Я надеюсь, что Nashorn рано или поздно уйдет в историю, и у нас будет возможность писать части кода на разных языках в одном исходнике. Но это пока только мечты.

Spring Framework: предложение, от которого сложно отказаться?

В Spring есть встроенная поддержка исполнения скриптов, построенная на базе API JDK. В пакете org.springframework.scripting.* можно найти много полезных классов — все, чтобы можно было удобно использовать низкоуровневый API для скриптинга в своем приложении.

Кроме этого, есть более высокоуровневая поддержка, она подробно описана в документации. Вкратце — нужно сделать класс на скриптовом языке (например, Groovy) и опубликовать его как бин через XML описание:

После того, как бин опубликован, его можно добавлять в свои классы при помощи IoC. Spring обеспечивает автоматическое обновление скрипта при изменении текста в файле, можно вешать аспекты на методы и т.д.

Выглядит неплохо, но нужно делать “настоящие” классы для того, чтобы их опубликовать, обычную функцию в скрипте не напишешь. Кроме того, скрипты можно хранить только в файловой системе, для использования БД придется лезть внутрь Spring. Да и XML конфигурацию многие считают устаревшей, особенно если в приложении уже все на аннотациях. Это, конечно, вкусовщина, но с ней зачастую приходится считаться.

Скрипты: трудности и идеи

Итак, у каждого решения есть своя цена, и, если говорить о скриптах в Java приложениях, то при внедрении этой технологии можно столкнуться с некоторыми трудностями:

Вдобавок ко всему, если каждый скрипт будет связан только с одним методом, можно быстро найти все точки вызова в приложении при помощи меню “Find Usages” из IDE и понять место скрипта в каждом конкретном алгоритме бизнес-логики.

Упрощается тестирование — оно превращается в “обычное” тестирование классов, с использованием привычных фреймворков, mock’ами и прочим.

Все вышеописанное очень созвучно с идеей, упомянутой в начале статьи — “специальные” классы для методов, которые реализуются скриптами. А что, если сделать ещё один шаг и скрыть весь служебный однотипный код для вызовов скриптовых движков от разработчика, чтобы он про это даже не думал (ну, почти)?

Репозитории скриптов — концепт

Задумка довольно проста и должна быть знакома тем, кто хоть раз работал со Spring, особенно со Spring JPA. Что нужно — сделать Java интерфейс и при вызове его методов вызывать скрипт. В JPA, кстати, используется идентичный подход — вызов CrudRepository перехватывается, на основе имени метода и параметров создается запрос, который потом выполняется движком БД.

Что нужно, чтобы реализовать концепт?

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

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

Полезным дополнением будет возможность использовать методы с реализацией в интерфейсе (a.k.a. default) — этот код будет работать, пока бизнес-аналитик не выведает более полную версию алгоритма, а разработчик не сделает скрипт на основе
этой информации. Или пусть аналитик скрипт пишет, а разработчик потом просто скопирует его на сервер. Вариантов много 🙂

Итак, предположим, что для интернет-магазина нужно сделать сервис для вычисления скидок на основе профиля пользователя. Прямо сейчас непонятно, как это делать, но бизнес-аналитик клянется, что всем зарегистрированным пользователям полагается скидка 10%, остальное он выяснит в течение недели у заказчика. Сервис нужен прямо завтра — сезон все-таки. Как может выглядеть код для такого случая?

А потом подоспеет и сам алгоритм, написанный, например, на groovy, там скидки будут немного отличаться:

Вызов читаемый, понятный, и, чтобы его сделать, не надо обладать никакими особыми навыками.

Это были идеи, на основе которых была сделана небольшая библиотека для работы со скриптами. Она предназначена для Spring приложений, этот фреймворк использовался для создания библиотеки. В ней предоставляется расширяемый API для загрузки скриптов из различных источников и их выполнения, который скрывает рутинную работу со скриптовыми движками.

Как это работает

Общее устройство библиотеки показано на диаграмме. Синим выделены компоненты, которые нужно разработать, белым — которые уже есть в библиотеке. Значком Spring помечены компоненты, которые доступны в контексте Spring.

Когда вызывается метод интерфейса (по факту — прокси-объекта), запускается обработчик вызова, который в контексте приложения ищет два бина: провайдера, который будет искать текст скрипта, и исполнителя, который, собственно, найденный текст будет выполнять. Потом обработчик возвращает результат вызвавшему методу.

Можно заметить аннотации @ScriptParam — они нужны для того, чтобы указывать имена параметров при передаче их в скрипт, поскольку Java компилятор стирает исходные имена из исходников (есть способы заставить его это не делать, но лучше на это не полагаться). Можно имена параметров и не указывать, но, в таком случае, в скрипте нужно будет использовать “arg0”, “arg1”, что не сильно улучшает читаемость.

Тестирование и версионирование

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

Если нужно версионирование, то можно создать провайдера, который будет читать разные версии скриптов из файловой системы, из базы данных или из Git, например. Так можно будет легко организовать откат на предыдущую версию скрипта в случае неполадок на основном сервере.

Итого

Представленная библиотека поможет организовать скрипты в Spring приложении:

Источник

Сисадмину: Пишем скрипты на все случаи жизни

Каждый, кто работал сисадмином UNIX-систем, рано или поздно начинает автоматизировать свою работу с помощью скриптов.
Написаны они могут быть на чём угодно — от bash’а до tcl. Важен подход.
В этой статье я попробую вкратце описать приемы скриптовой автоматизации.

Когда нужно писать скрипты?

1. Когда это приведет к экономии времени.
Если нужно однотипно настроить 1000 свитчей, разослать спам приглашения на конференцию или собрать базу MAC-адресов — скрипты наши лучшие друзья.

2. Когда некие действия выполняются регулярно.
Архивирования резервных копий, очистка mysql-базы от мусора или сбор статистики — те самые случаи.

3. Когда нужно создать что-то сложное, но лениво делать это «по серьёзному».
Примеры — микробиллинги, счетчики трафика и системы блокировки должников.
Это нужно писать на C/C++. Но начальство сказало: «Сделать сегодня!». И снова скрипты — и мысль «когда-нибудь перепишу». 🙂

Когда не нужно писать скрипт?

Всегда, когда это не нужно согласно трём первым пунктам.
Хотя если хотите — пишите. Время ваше. 🙂

Несколько примеров из личной жизни

1. Скрипт починки всех таблиц mysql. Ставил на хостинг по крону — сразу пропали звонки абонентов на тему неработающих сайтов на mysql. [bash]

2. Массовое выполнение команд на свитчах AT-8000S. [perl]

iplist.txt — список свитчей в формате ip:login:password
command.txt — список команд.

3. Проверка работы демона — полезно при наличии падучих программ.
Можно убрать while и запихнуть в кронтаб.

Заключение

Скрипты можно писать. Скрипты нужно писать. Удачи. 🙂

Источник

Магия консоли 2. Запасаемся инструментами на все случаи жизни

Содержание статьи

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

Netfilter

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

Есть под­дер­жка нес­коль­ких аплинков и VPN. А еще автор спе­циаль­но ста­рает­ся дер­жать скрип­ты для iptables и nftables мак­сималь­но похожи­ми, что­бы облегчить миг­рацию тем, кто еще это­го не сде­лал.

Фраг­мент скрип­та

adbwebkit

Adbwebkit — это хорошая веб‑мор­да для вза­имо­дей­ствия с устрой­ством на Android по ADB. Пред­став­ляет собой пач­ку скрип­тов на PHP, которые пар­сят вывод штат­ного кли­ента ADB в сис­теме и выводят резуль­тат в веб‑интерфейс. Мне при­годи­лось для работы с телефо­ном, у которо­го очень пло­хо работал сен­сор, а дос­туп к сис­теме был нужен.

Ус­танов­ка дела­ется в четыре коман­ды, вклю­чая уста­нов­ку зависи­мос­тей:

Пос­ле это­го веб‑интерфейс ста­нет дос­тупен по адре­су localhost:8000.

Де­мо из репози­тория про­екта

Дашборды

Cockpit

Cockpit — это не сов­сем даш­борд. Это боль­шая веб‑кон­соль для управле­ния сер­вером.

Ус­танов­ка мак­сималь­но прос­та:

За­тем нуж­но открыть порт 9090 на фай­рво­ле:

Даль­ше мож­но нас­тро­ить дос­туп через реверс‑прок­си nginx по име­ни хос­та с нор­маль­ными SSL-сер­тифика­тами и на при­выч­ных пор­тах.

Пос­ле всех манипу­ляций заходим на твой-хост>: 9090 и видим окно логина. В него вби­ваем имя поль­зовате­ля и пароль дей­стви­тель­ной учет­ной записи на сер­вере и видим даш­борд.

За упав­ший сер­вис не пинай — так задума­но

Cockpit уме­ет рисовать гра­фики боль­шинс­тва инте­рес­ных мет­рик — в час­тнос­ти, заг­рузки дис­ка.

Disk I/O graph

На вклад­ке Host дос­тупны дей­ствия с сер­вером: уста­нов­ка обновле­ний, рулеж­ка сер­висами, управле­ние питани­ем и так далее.

На­чина­юще­му адми­ну это может здо­рово облегчить жизнь.

Пом­нишь bashtop из прош­лой серии? Btop++ — это его реали­зация на C++ с повышен­ной про­изво­дитель­ностью. Умень­шен­ный интервал обновле­ния гра­фиков не при­водит к зна­читель­ному повыше­нию наг­рузки на про­цес­сор. При этом даш­борд выг­лядит столь же кра­соч­но и эффек­тно для неис­кушен­ного посети­теля тво­ей сер­верной!

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник