Создание и запуск скрипта. Как писать и как запускать скрипты PowerShell

С помощью скриптов R можно быстро и бесплатно собирать данные из API различных сервисов или рекламных площадок и записывать их в базу данных. Но если вы регулярно пользуетесь скриптами, то есть ли смысл каждый раз запускать их вручную?

Я расскажу, как настроить запуск скриптов R с определенным интервалом в операционной системе Windows.

1. Как добавить путь к R-консоли в переменную окружения PATH?

PATH — переменная окружения Unix-подобных операционных систем, DOS, OS/2 и Microsoft Windows, представляющая собой набор директорий, в которых расположены исполняемые файлы. В основном, каждый выполняемый процесс или сеанс пользователя имеет собственную переменную PATH.

Эта инструкция относится к операционным системам Windows 8 и 10, но вы без проблем можете подробные руководства и для любой другой версии Windows.
1.1. В строке «Поиск» найдите «Система (Панель управления)» и нажмите на ссылку «Дополнительные параметры системы».

1.2. В окне свойств системы нажмите на кнопку «Переменные среды...».

1.3. В разделе «Переменные среды» кликните на переменную PATH и нажмите «Изменить». Если переменной PATH не существует, нажмите «Создать».

1.4. Добавьте в переменную путь к папке с файлом «R.exe ».

Bat-файл, по сути, похож на файл с расширением exe, но его код более простой и состоит из некоторых командных строк.

Создать bat-файл довольно просто. Можно записать команду запуска в обычный текстовый файл с расширением TXT, сохранить его и поменять расширение на «.bat ». Я опишу другой способ — создание bat-файла с помощью бесплатного блокнота Notepad++.

2.1. Откройте Notepad++ (скачать его можете по ссылке).

2.2. Введите следующую команду:

@echo off R CMD BATCH C:\R\myscript.R

Команда «@echo off » отключает вывод сообщений в командной строке при работе скрипта, вы можете изменить эту команду на «@echo on » и наблюдать за выполнением скрипта в ходе его работы.

Команда «R CMD BATCH » запускает выполнение R скрипта.

Во второй строке вместо «C:\R\myscript.R» пропишите путь к вашему файлу со скриптом R.

В результате файл будет выглядеть так:

2.3. Сохраните созданный текстовый файл с расширением BAT. Для этого в меню Notepad++ выберите пункт «Файл» — «Сохранить как» — «Batch file (bat, cmd, nt)».

Если вы не хотите, чтобы при автозапуске R-скрипта на экране появлялось окно командной строки, то скомпилируйте ваш bat-файла в exe — в таком случае скрипт будет работать в фоновом режиме и не будет вам мешать.

3.1. Скачайте бесплатную утилиту «Bat To Exe Converter» по ссылке .

3.2. Укажите bat-файл, который необходимо скомпилировать, а также путь и название будущего exe-файла.

3.3. В области «Видимость приложения» установите переключатель в положение «Невидимое приложение».

3.4. При желании установите иконку для вашего файла.

Чтобы установить иконку, перейдите на вкладку «Информация о версии» и с помощью кнопки «...» выберите нужную иконку в поле «Файл значка».

В качестве иконки можете использовать любое изображение в формате ICO или же нарисовать самостоятельно в бесплатном онлайн-редакторе .

Нажмите кнопку «Компилировать».

4. Настройте планировщик задач Windows

Заключительный этап настройки — добавить задачу в планировщик задач Windows.

Планировщик задач Windows — встроенная утилита (аналог линуксового CRON), с помощью которой можно запланировать в определенное время с заданными условиями:

запуск любой программы;
отправку электронной почты;
вывод на экран определенного сообщения.

4.1. Чтобы открыть планировщик задач, скопируйте в адресную строку открытой папки путь «%windir%\system32\taskschd.msc /s ».

4.2. В правой части планировщика выберите пункт «Создать задачу...».

4.3. На вкладке «Общие» в диалоговом окне «Создание задачи» введите название и при необходимости краткое описание.

4.4. На вкладке «Триггеры» настройте расписание запуска скрипта: нажмите «Создать» и установите, к примеру, повтор запуска скрипта каждый понедельник в 12:45.

На этом процесс настройки запуска R скриптов по расписанию закончен. Если вы все сделали правильно, в списке появится новая задача.

Вывод

С этим руководством настройка автозапуска займет не более десяти минут, и поможет сэкономить время в будущем.

Алгоритм действий:

В переменной окружения PATH пропишите путь к консоли R.
Создайте скрипт R, который будет выполнять нужные действия (например, сохранять результат в файл формата CSV или записывать в базу данных).
Создайте bat-файл, в котором будет прописан путь к скрипту R.
Скомпилируйте ваш bat-файла в exe, чтобы он запускался в фоновом режиме и не отвлекал от работы.
В планировщике задач Windows добавьте повторяющееся задание на запуск bat-файла и установите определенный интервал времени.

Обрабатывать огромные массивы данных, агрегировать и передавать их в любые базы — просто и быстро, если вы правильно организовали свою работу.

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

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

Сигналы Linux

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

Код сигнала	Название	Описание
1	SIGHUP	Закрытие терминала
2	SIGINT	Сигнал остановки процесса пользователем с терминала (CTRL + C)
3	SIGQUIT	Сигнал остановки процесса пользователем с терминала (CTRL + \) с дампом памяти
9	SIGKILL	Безусловное завершение процесса
15	SIGTERM	Сигнал запроса завершения процесса
17	SIGSTOP	Принудительная приостановка выполнения процесса, но не завершение его работы
18	SIGTSTP	Приостановка процесса с терминала (CTRL + Z), но не завершение работы
19	SIGCONT	Продолжение выполнения ранее остановленного процесса

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

Сигнал SIGINT приводит к временной остановке работы. Ядро Linux перестаёт выделять оболочке процессорное время. Когда это происходит, оболочка уведомляет процессы, отправляя им сигнал SIGINT .

Bash-скрипты не контролируют эти сигналы, но они могут распознавать их и выполнять некие команды для подготовки скрипта к последствиям, вызываемым сигналами.

Отправка сигналов скриптам

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

Завершение работы процесса

Комбинация клавиш CTRL + C генерирует сигнал SIGINT и отправляет его всем процессам, выполняющимся в оболочке, что приводит к завершению их работы.

Выполним в оболочке такую команду:

$ sleep 100
После этого завершим её работу комбинацией клавиш CTRL + C .

Завершение работы процесса с клавиатуры

Временная остановка процесса

Комбинация клавиш CTRL + Z позволяет сгенерировать сигнал SIGTSTP , который приостанавливает работу процесса, но не завершает его выполнение. Такой процесс остаётся в памяти, его работу можно возобновить. Выполним в оболочке команду:

$ sleep 100
И временно остановим её комбинацией клавиш CTRL + Z .

Приостановка процесса

Число в квадратных скобках - это номер задания, который оболочка назначает процессу. Оболочка рассматривает процессы, выполняющиеся в ней, как задания с уникальными номерами. Первому процессу назначается номер 1, второму - 2, и так далее.

Если вы приостановите задание, привязанное к оболочке, и попытаетесь выйти из неё, bash выдаст предупреждение.

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

Ps –l

Список заданий

В колонке S , выводящей состояние процесса, для приостановленных процессов выводится T . Это указывает на то, что команда либо приостановлена, либо находится в состоянии трассировки.

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

Выглядит её вызов так:

Kill processID

Перехват сигналов

Для того, чтобы включить в скрипте отслеживание сигналов Linux, используется команда trap . Если скрипт получает сигнал, указанный при вызове этой команды, он обрабатывает его самостоятельно, при этом оболочка такой сигнал обрабатывать не будет.

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

Рассмотрим пример, в котором показано, как при вызове команды trap задаётся код, который надо выполнить, и список сигналов, разделённых пробелами, которые мы хотим перехватить. В данном случае это всего один сигнал:

#!/bin/bash trap "echo " Trapped Ctrl-C"" SIGINT echo This is a test script count=1 while [ $count -le 10 ] do echo "Loop #$count" sleep 1 count=$(($count + 1)) done
Команда trap , использованная в этом примере, выводит текстовое сообщение всякий раз, когда она обнаруживает сигнал SIGINT , который можно сгенерировать, нажав Ctrl + C на клавиатуре.

Перехват сигналов

Каждый раз, когда вы нажимаете клавиши CTRL + C , скрипт выполняет команду echo , указанную при вызове trace вместо того, чтобы позволить оболочке завершит его работу.

Перехватить сигнал выхода из скрипта можно, использовав при вызове команды trap имя сигнала EXIT:

#!/bin/bash trap "echo Goodbye..." EXIT count=1 while [ $count -le 5 ] do echo "Loop #$count" sleep 1 count=$(($count + 1)) done

Перехват сигнала выхода из скрипта

При выходе из скрипта, будь то нормальное завершение его работы или завершение, вызванное сигналом SIGINT , сработает перехват и оболочка исполнит команду echo .

Модификация перехваченных сигналов и отмена перехвата

Для модификации перехваченных скриптом сигналов можно выполнить команду trap с новыми параметрами:

#!/bin/bash trap "echo "Ctrl-C is trapped."" SIGINT count=1 while [ $count -le 5 ] do echo "Loop #$count" sleep 1 count=$(($count + 1)) done trap "echo " I modified the trap!"" SIGINT count=1 while [ $count -le 5 ] do echo "Second Loop #$count" sleep 1 count=$(($count + 1)) done

Модификация перехвата сигналов

После модификации сигналы будут обрабатываться по-новому.

Перехват сигналов можно и отменить, для этого достаточно выполнить команду trap , передав ей двойное тире и имя сигнала:

#!/bin/bash trap "echo "Ctrl-C is trapped."" SIGINT count=1 while [ $count -le 5 ] do echo "Loop #$count" sleep 1 count=$(($count + 1)) done trap -- SIGINT echo "I just removed the trap" count=1 while [ $count -le 5 ] do echo "Second Loop #$count" sleep 1 count=$(($count + 1)) done
Если скрипт получит сигнал до отмены перехвата, он обработает его так, как задано в действующей команде trap . Запустим скрипт:

$ ./myscript
И нажмём CTRL + C на клавиатуре.

Сигнал, перехваченный до отмены перехвата

Первое нажатие CTRL + C пришлось на момент исполнения скрипта, когда перехват сигнала был в силе, поэтому скрипт исполнил назначенную сигналу команду echo . После того, как исполнение дошло до команды отмены перехвата, команда CTRL + C сработала обычным образом, завершив работу скрипта.

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

Иногда bash-скриптам требуется немало времени для выполнения некоей задачи. При этом вам может понадобиться возможность нормально работать в командной строке, не дожидаясь завершения скрипта. Реализовать это не так уж и сложно.

Если вы видели список процессов, выводимый командой ps , вы могли заметить процессы, которые выполняются в фоне и не привязаны к терминалу.
Напишем такой скрипт:

#!/bin/bash count=1 while [ $count -le 10 ] do sleep 1 count=$(($count + 1)) done
Запустим его, указав после имени символ амперсанда (&):

$ ./myscipt &
Это приведёт к тому, что он будет запущен как фоновый процесс.

Запуск скрипта в фоновом режиме

Скрипт будет запущен в фоновом процессе, в терминал выведется его идентификатор, а когда его выполнение завершится, вы увидите сообщение об этом.

Обратите внимание на то, что хотя скрипт выполняется в фоне, он продолжает использовать терминал для вывода сообщений в STDOUT и STDERR , то есть, выводимый им текст или сообщения об ошибках можно будет увидеть в терминале.

Список процессов

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

Что если нужно, чтобы скрипт продолжал работать и после закрытия терминала?

Выполнение скриптов, не завершающих работу при закрытии терминала

Скрипты можно выполнять в фоновых процессах даже после выхода из терминальной сессии. Для этого можно воспользоваться командой nohup . Эта команда позволяет запустить программу, блокируя сигналы SIGHUP , отправляемые процессу. В результате процесс будет исполняться даже при выходе из терминала, в котором он был запущен.

Применим эту методику при запуске нашего скрипта:

Nohup ./myscript &
Вот что будет выведено в терминал.

Команда nohup

Команда nohup отвязывает процесс от терминала. Это означает, что процесс потеряет ссылки на STDOUT и STDERR . Для того, чтобы не потерять данные, выводимые скриптом, nohup автоматически перенаправляет сообщения, поступающие в STDOUT и в STDERR , в файл nohup.out .

Обратите внимание на то, что при запуске нескольких скриптов из одной и той же директории то, что они выводят, попадёт в один файл nohup.out .

Просмотр заданий

Команда jobs позволяет просматривать текущие задания, которые выполняются в оболочке. Напишем такой скрипт:

#!/bin/bash count=1 while [ $count -le 10 ] do echo "Loop #$count" sleep 10 count=$(($count + 1)) done
Запустим его:

$ ./myscript
И временно остановим комбинацией клавиш CTRL + Z .

Запуск и приостановка скрипта

Запустим тот же скрипт в фоновом режиме, при этом перенаправим вывод скрипта в файл так, чтобы он ничего не выводил на экране:

$ ./myscript > outfile &
Выполнив теперь команду jobs , мы увидим сведения как о приостановленном скрипте, так и о том, который работает в фоне.

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

Ключ -l при вызове команды jobs указывает на то, что нам нужны сведения об ID процессов.

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

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

Запустим скрипт:

$ ./myscript
Нажмём CTRL + Z , что временно остановит его выполнение. Выполним следующую команду:

$ bg

Команда bg

Теперь скрипт выполняется в фоновом режиме.

Если у вас имеется несколько приостановленных заданий, для перезапуска конкретного задания команде bg можно передать его номер.

Для перезапуска задания в обычном режиме воспользуйтесь командой fg:

Планирование запуска скриптов

Linux предоставляет пару способов запуска bash-скриптов в заданное время. Это команда at и планировщик заданий cron .

Вызов команды at выглядит так:

At [-f filename] time
Эта команда распознаёт множество форматов указания времени.

Стандартный, с указанием часов и минут, например - 10:15.
С использованием индикаторов AM/PM, до или после полудня, например - 10:15PM.
С использованием специальных имён, таких, как now , noon , midnight .

В дополнение к возможности указания времени запуска задания, команде at можно передать и дату, используя один из поддерживаемых ей форматов.

Стандартный формат указания даты, при котором дата записывается по шаблонам MMDDYY , MM/DD/YY , или DD.MM.YY .
Текстовое представление даты, например, Jul 4 или Dec 25 , при этом год можно указать, а можно обойтись и без него.
Запись вида now + 25 minutes .
Запись вида 10:15PM tomorrow .
Запись вида 10:15 + 7 days .

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

$ at -f ./myscript now

Планирование заданий с использованием команды at

Ключ -M при вызове at используется для отправки того, что выведет скрипт, по электронной почте, если система соответствующим образом настроена. Если отправка электронного письма невозможна, этот ключ просто подавит вывод.

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

Список заданий, ожидающих выполнения

Удаление заданий, ожидающих выполнения

Удалить задание, ожидающее выполнения, позволяет команда atrm . При её вызове указывают номер задания:

$ atrm 18

Удаление задания

Запуск скриптов по расписанию

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

В Linux имеется утилита crontab , позволяющая планировать запуск скриптов, которые нужно выполнять регулярно.

Crontab выполняется в фоне и, основываясь на данных в так называемых cron-таблицах, запускает задания по расписанию.

Для того, чтобы просмотреть существующую таблицу заданий cron , воспользуйтесь такой командой:

$ crontab –l
При планировании запуска скрипта по расписанию crontab принимает данные о том, когда нужно выполнить задание, в таком формате:

Минута, час, день месяца, месяц, день недели.
Например, если надо, чтобы некий скрипт с именем command выполнялся ежедневно в 10:30, этому будет соответствовать такая запись в таблице заданий:

30 10 * * * command
Здесь универсальный символ « * », использованный для полей, задающих день месяца, месяц и день недели, указывает на то, что cron должен выполнять команду каждый день каждого месяца в 10:30.

Если, например, надо, чтобы скрипт запускался в 4:30PM каждый понедельник, понадобится создать в таблице заданий такую запись:

30 16 * * 1 command
Нумерация дней недели начинается с 0, 0 означает воскресенье, 6 - субботу. Вот ещё один пример. Здесь команда будет выполняться в 12 часов дня в первый день каждого месяца.

00 12 1 * * command
Нумерация месяцев начинается с 1.
Для того чтобы добавить запись в таблицу, нужно вызвать crontab с ключом -e:

Crontab –e
Затем можно вводить команды формирования расписания:

30 10 * * * /home/likegeeks/Desktop/myscript
Благодаря этой команде скрипт будет вызываться ежедневно в 10:30. Если вы столкнётесь с ошибкой «Resource temporarily unavailable», выполните нижеприведённую команду с правами root-пользователя:

$ rm -f /var/run/crond.pid
Организовать периодический запуск скриптов с использованием cron можно ещё проще, воспользовавшись несколькими специальными директориями:

/etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
Если поместить файл скрипта в одну из них, это приведёт, соответственно, к его ежечасному, ежедневному, еженедельному или ежемесячному запуску.

Запуск скриптов при входе в систему и при запуске оболочки

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

$HOME/.bash_profile $HOME/.bash_login $HOME/.profile
Для того, чтобы запускать скрипт при входе в систему, поместите его вызов в файл.bash_profile .

А как насчёт запуска скриптов при открытии терминала? Организовать это поможет файл.bashrc .

Итоги

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

Уважаемые читатели! А вы пользуетесь средствами планирования запуска сценариев командной строки по расписанию? Если да - расскажите пожалуйста о них.

Не один год прошел с момента выхода Windows 7 и Server 2008.

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

Начинающие же юзеры в большинстве своём даже не знают, что такое PowerShell (PS).

А ведь скрипты для PowerShell позволяют автоматизировать, без малого, 100% действий и сценариев, выполняемых в операционной системе посредством командной строки и графического интерфейса.

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

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

Что собой представляет Windows PowerShell?

PowerShell – интерпретатор на основе.NET Framework, наделённый собственным языком сценариев.

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

Как это было в MS-DOS и старых версиях UNIX’а.

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

По сравнению с другими интерпретаторами, PS отличается:

интеграцией с. – позволяет создавать мощные скрипты, внедряя в них программный код;
все возвращаемые данные являются объектами, а не данными текстового/строчного типа (string), что подразумевает их передачу другим скриптам и любую обработку.

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

Возможность представления команд в виде командлетов – их запуск осуществляется внутри интерпретатора, в ином случае команда выполняется в отдельном процессе.
Использование конвейеров – предназначены для передачи данных из одной команды в другую с сохранением их структуры и типа.
Интегрирована многопоточная передача данных по сети с установкой приоритетности и возобновлением соединения.
Поддержка позиционных и именованных параметров.
Фоновая работа – асинхронный вызов команд и запуск скриптов на удалённых машинах.
Установка ограниченных сессий с удалёнными клиентами и выполнение сценариев на них.
Модули – способ организации скриптов, когда они становятся самодостаточными и выполняются в собственном контейнере, не влияя на окружение модуля.
Наличие обработчика ошибок.
Графическая среда для языка : синтаксис, отладчик, подсветка, автоматическое завершение команд с поддержкой Юникод и закладок.
Добавление точек прерывания в строки , команды, операции и переменные для отладки сценария.
Блочные и подстрочные комментарии.
Поддержка создания алиасов для некоторых командлетов , преобразовывающихся в обычные команды в момент выполнения.
Создание ограниченных сессий, где можно выполнять строго заданный перечень команд и очень многое другое.

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

Приступать к освоению интегрированного скриптового языка, не имея навыков программирования, можно.

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

Хотя, не обладая знаниями об основных понятиях PowerShell, сделать в окне командного интерпретатора вряд ли что-либо получится. С них и начнём.

Командлеты

Командлеты – своеобразные команды PS, за которыми скрываются самые разные функции. Встроенные в интерпретатор команды реализованы по принципу «глагол-имя существительное», например, Get-Process (получение списка процессов). Такое решение позволяет понимать суть команды уже из её названия (на английском языке).

Часть командлетов поддерживает получение/передачу данных и массивов информации с сохранением их структуры и типа. Это работает по принципу конвейера (речь об этом пойдёт в следующем разделе). Несмотря ни на что, командлеты запускаются и обрабатывают объекты строго порядку.

Для реализации командлетов могут задействоваться любые поддерживаемые.NET API, созданные на любом из.NET-языков.

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

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

Посредством командлетов можно работать , объектами файловой системы и хранилища сертификатов, установленными приложениями и службами.

Конвейер

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

Для этого существует конвейер. Как и в UNIX, он объединяет команды путём передачи выходных данных одного командлета во входные для другого в неизменном виде, сохраняя свой тип.

При этом не требуются никакой контейнер или посимвольный разбор информации.

В состав передаваемой информации может входить и функция. После окончания работы объединённых команд вызывается функция превращения информации в текстовый вид (конвертация данных в строковые) с применением форматирования текста.

Скрипты

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

Особенно, когда одни и те же операции следует выполнять постоянно.

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

Для выполнения однообразных цепочек действий в PS реализованы сценарии – текстовые файлы с последовательностью понятных для интерпретатора команд внутри.

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

Но здесь «не всё золото, что блестит»: написать собственный сценарий или загрузить готовый (пускай и немного подогнав его под собственные цели) так просто не получится.

Если бы в Microsoft это разрешили, сколько бы бед наделали скрипты для PowerShell , написанные мошенниками и недоброжелателями в корыстных или хулиганских целях.

Для выполнения в Windows PS необходимо пройти контроль его запуска.

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

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

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

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

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

Преднамеренный запуск макросов происходит после изменения уровня безопасности, если юзер даст добро, осознавая, что он делает, и зная наверняка, что в файле *.ps1 находится.

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

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

Оболочка обладает тремя уровнями безопасности:

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

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

Существует и понятие политики выполнения, созданной с целью предотвратить случайный запуск сценариев. Настроек политики запуска существует целых пять:

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

Проверить текущее состояние политики запуска можно командой «Get-ExecutionPolicy» . Какой бы ни была политика безопасности, пользователь не сможет запустить скрипт, в котором содержатся команды, на выполнение коих у него недостаточно привилегий.

Запуск PowerShell

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

Вызвать окно PowerShell можно несколькими путями.

Представлено оно в двух видах:

классическая консоль;

PowerShell ISE – добавляет поддержку вкладок, синтаксиса, контекстной справки, контекстного и главного и меню, что в значительной мере облегчает работу в интерпретаторе.

Пуск

Проще всего вызвать PS через Пуск .

Открываем меню (в Windows 7 кликаем «Все программы»).
Идём в каталог Windows PowerShell и кликаем по нужной иконке.

Рис. 6 – Запуск PS через диалог «Выполнить»

Win+X

В Windows 10 PS можно вызывать из меню WinX. Дело в том, что по умолчанию путём клика по команде «Командная строка» открываемся CMD. Её можно заменить на PowerShell.

Открываем «Свойства» Панели задач, во вкладке «Навигация» ставим галочку возле единственной опции и сохраняем настройки.

Можно вызывать PowerShell через командную строку, прописав в ней «powershell» или запуском исполняемого файла по пути: %WINDIR%\System32\ WindowsPowerShell\v1.0 для 32-битных систем и по адресу %WINDIR%\ syswow64\ WindowsPowerShell\v1.0 для 64-разрядных Windows любой редакции.

Рис. 8 – Запуск PS из каталога, где хранится его исполняемый файл

В простейшем случае, шелл скрипт (shell script) -- это ни что иное, как простая последовательность команд системы, записанная в простой текстовый файл. Создание скриптов поможет сохранить ваше время и силы, которые тратятся на ввод последовательности команд всякий раз, когда необходимо их выполнить. Например:

Шелл скрипт для очистки лог-файлов в /var/log

# cleanup
cd / var/ log
cat / dev/ null > messages
cat / dev/ null > wtmp
echo "Лог-файлы очищены."

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

Sha-bang

Sha-bang - это двухбайтовая последовательность #! , после которой указывается, какой интерпретатор необходимо использовать для запуска скрипта, интерпретации и выполнения команд. В качестве интерпретатора может выступать как одна из системных оболочек (см. файл /etc/shells ) например bash или csh так и любой другой интерпретатор команд или просто утилита. Вот несколько примеров маркера sha-bang :

#!/bin/sh #!/bin/bash #!/usr/bin/perl #!/usr/bin/tcl #!/bin/sed -f #!/usr/awk -f

Каждая, из приведенных выше сигнатур, вызывает определенный интерпретатор, будь то /bin/sh -- командный интерпретатор по-умолчанию (bash для Linux-систем), либо иной. При переносе сценариев с сигнатурой #!/bin/sh на другие , где в качестве командного интерпретатора установлена другая системная оболочка, вы можете лишиться некоторых функциональных возможностей, присущих bash . Поэтому такие сценарии должны быть POSIX совместимыми.

P ortable O perating S ystem I nterface, попытка стандартизации UNIX -подобных операционных систем.

Если кроме первой строки, встречаются другие аналогичные строки, они будут восприняты как обычный комментарий.

#!/bin/bash
echo "Первая часть сценария."
a =1
#!/bin/bash
# Это *НЕ* означает запуск нового сценария.
echo "Вторая часть сценария."
echo $a # Значение переменной $a осталось равно 1.

Обратите внимание на то, что сигнатура должна указывать правильный путь к интерпретатору, в противном случае вы получите сообщение об ошибке -- как правило это "Command not found".

Сигнатуру #! можно не указывать, если вы не используете команд специфичных для какого-то конкретного интерпретатора. Например как в расширенной версии скрипте, представленной ниже. Здесь используется специфическая конструкция присвоения значения переменной lines=50 .

Еще раз замечу, что сигнатура #!/bin/sh вызывает командный интерпретатор по-умолчанию -- /bin/bash в Linux-системах.

Расширенная версия предыдущего шелл скрипта

#!/bin/bash
# cleanup, version 2
# Для работы сценария требуются права root.
LOG_DIR =/ var/ log
ROOT_UID =0 # Только пользователь с $UID 0 имеет привилегии root.
LINES =50 # Количество сохраняемых строк по-умолчанию.
E_XCD =66 # Невозможно сменить каталог?
E_NOTROOT =67 # Признак отсутствия root-привилегий.
if [ "$UID " -ne "$ROOT_UID " ]
then
echo "Для работы сценария требуются права root."
exit $E_NOTROOT
if [ -n "$1" ]
# Проверка наличия аргумента командной строки.
then
lines =$1
else
lines =$LINES # Значение по-умолчанию, если число не задано в командной строке
# Stephane Chazelas предложил следующее,
#+ для проверки корректности аргумента, переданного из командной строки,
#+ правда это достаточно сложно для данного руководства.
# E_WRONGARGS=65 # Не числовой аргумент
# case "$1" in
# "") lines=50;;
# *[!0-9]*) echo "Usage: `basename $0` file-to-cleanup"; exit $E_WRONGARGS;;
# *) lines=$1;;
# esac
#* Конец проверки корректности аргумента
cd $LOG_DIR
if [ ` pwd ` ! = "$LOG_DIR " ] # или if [ "$PWD" != "$LOG_DIR" ]
# Не в /var/log?
then
echo "Невозможно перейти в каталог $LOG_DIR ."
exit $E_XCD
fi # Проверка каталога перед очисткой лог-файлов.
# более эффективный вариант:
# cd /var/log || {
# echo "Невозможно перейти в требуемый каталог." >&2
# exit $E_XCD;
tail -$lines messages > mesg.temp # Сохранить последние строки в лог-файле.
mv mesg.temp messages
# cat /dev/null > messages
#* Необходимость этой команды отпала, поскольку очистка выполняется выше.
cat / dev/ null > wtmp # команды ": > wtmp" и "> wtmp" имеют тот же эффект.
echo "Лог-файлы очищены."
exit 0
# Возвращаемое значение 0
#+ указывает на успешное завершение работы сценария.

Если вам не нужно целиком вычищать системные логи, обратите внимание на приведенный выше скрипт. Здесь сохраняются последние несколько строк (по-умолчанию -- 50).

Запуск скриптов

Запустить скрипт системной оболочки можно командой sh scriptname или bash scriptname . Более удобный вариант -- сделать файл скрипта исполняемым, командой chmod .

Chmod 555 scriptname # установить права на чтение/исполнение любому пользователю в системе.

Chmod +rx scriptname # установить права на чтение/исполнение любому пользователю в системе chmod u+rx scriptname # установить права на чтение/исполнение только владельцу скрипта

После того, как вы сделаете файл сценария исполняемым, вы можете запустить его примерно такой командой ./scriptname . При этом, если текст скрипта начинается с корректной сигнатуры sha-bang , для выполнения данного скрипта будет вызван соответствующий интерпретатор.

И наконец, завершив отладку сценария, вы можете поместить его в каталог /usr/local/bin (естественно, что для этого вы должны обладать правами root), чтобы сделать его доступным для себя и других пользователей системы. После этого сценарий можно вызвать, просто напечатав название файла в командной строке и нажав ENTER .

1. Написание скрипта

Скрипт PowerShell (не важно какой версии) - это текстовый файл с расширением *.ps1 .

Вот пример простого Power Shell срипта (файл systemInfo.ps1 ):

# Retrieve WMI object for the operating system

Get-WmiObject Win32_OperatingSystem

Этот файл можно создавать и редактировать, например, в FAR Manager.

Обратите внимание , что FAR Manager хоть и может работать в консоли Power Shell, но выполняет из-под себя скрипты в окружении обычной Windows-консоли cmd . То есть, FAR Manager можно использовать только для создания и редактирования PowerShell скриптов, но не для запуска. Но прежде чем разочаровываться, прочитайте пункт 3.

2. Запуск срипта

Скрипт нужно выполнять из консоли Power Shell, а не из обычной консоли Windows. В консоли Power Shell необходимо перейти в каталог, где лежит скрипт (командами cd ), и затем запустить сам скрипт, обязательно прописав перед ним символы ".\" . Например, имеем путь к файлу скрипта d:\work\systemInfo.ps1 . Тогда команды запуска будут выглядеть так:

cd \

cd work

.\systemInfo.ps1

или так (просто указывается полный путь к скрипту):

d:\work\systemInfo.ps1

Скорее всего, при запуске скрипта появится следующая ошибка:

Не удается загрузить файл D:\work\systemInfo.ps1, так как выполнение скриптов запрещено для данной системы. Введите "get-help about_signing" для получения дополнительных сведений.

строка:1 знак: 18

CategoryInfo: NotSpecified: (:) , PSSecurityException

FullyQualifiedErrorId: RuntimeException

Ошибка появляется из-за того, что по-умолчанию в Power Shell включена максимальная политика безопасности, которая позволяет выполнять команды PowerShell в командной строке, но не позволяет в той же командной строке выполнить скрипт с командами PowerShell.

Чтобы резрешить выполнение PowerShell скриптов, нужно создать *.bat файл, например enableScript.bat со следующим содержимым:

powershell -Command Set-ExecutionPolicy RemoteSigned

Этот *.bat файл можно выполнить в любой консоли: хоть в PowerShell, хоть в обычной cmd . После выполнения этого файла, PowerShell-скрипты станут запускаться в консоли PowerShell.

3. Запуск PowerShell-скрипта из обычной Windows-консоли cmd

Скрипт PowerShell можно выполнить и из обычной консоли Windows. Для этого можно воспользоваться командой:

Powershell -File ./systemInfo.ps1

Таким образом можно выполнять скрипты прямо из FAR Manager, и они будут работать.

Но тут есть небольшая тонкость. Параметр -File срабатывает только на локальных путях, даже если путь указан относительный "./" . То есть, если *.ps1 - файл лежит на локальном диске C: или D: , то такой вызов будет работать. Но если попробовать выполнить скрипт, расположенный на доменном ресурсе, то скрипт не будет найден. Возможно, это исправят в следующих версиях PowerShell.