Как написать сценарий линукс

Содержание
  1. ИТ База знаний
  2. Полезно
  3. Навигация
  4. Серверные решения
  5. Телефония
  6. Корпоративные сети
  7. Курс по сетям
  8. 15 примеров команды PING для диагностики сети
  9. Руководство по команде grep в Linux
  10. Рекурсивно найти слово в файлах и папках Linux
  11. Как использовать команду Strings в Linux
  12. Как пользоваться vim в Linux
  13. Лучшие HEX – редакторы для Linux
  14. Включить root подключение через SSH
  15. Учимся писать базовые скрипты в Unix и Linux
  16. Идентификация оболочки.
  17. Выбор оболочки
  18. Выполнение команд
  19. Добавление комментариев
  20. Делаем файл исполняемым
  21. Использование команды if
  22. Понятие переменных
  23. Запрос пользователя на ввод данных
  24. Использование аргументов командной строки
  25. Различные способы создания циклов
  26. Использование оператора case
  27. Реакция на ошибки
  28. Как написать сценарий линукс
  29. Titiaiev / bash-guide-1.md
  30. Приемы написания скриптов в Bash
  31. Совет 1
  32. Совет 2
  33. Совет 3
  34. Совет 4
  35. Совет 5
  36. Совет 6
  37. Читают сейчас
  38. Редакторский дайджест
  39. Похожие публикации
  40. Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит
  41. Bash-скрипты, часть 6: функции и разработка библиотек
  42. Bash-скрипты: начало
  43. Вакансии
  44. Минуточку внимания
  45. Комментарии 46

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Курс по сетям

15 примеров команды PING для диагностики сети

Руководство по команде grep в Linux

Рекурсивно найти слово в файлах и папках Linux

Как использовать команду Strings в Linux

Как пользоваться vim в Linux

Лучшие HEX – редакторы для Linux

Включить root подключение через SSH

Еженедельный дайджест

Учимся писать базовые скрипты в Unix и Linux

Если вы еще не умеете писать скрипты в системах Unix и Linux, эта статья познакомит с основами написания скриптов.

Обучайся в Merion Academy

Пройди курс по сетевым технологиям

Идентификация оболочки.

Вы также можете определить свою основную оболочку, просмотрев файл /etc/passwd :

На выводе видно, что доступно всего девять оболочек.

Выбор оболочки

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

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

Выполнение команд

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

Добавление комментариев

Делаем файл исполняемым

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

Использование команды if

Команда if позволяет вам проверять условия или переменные. В примере ниже мы проверяем, запускается ли скрипт в пятницу.

Понятие переменных

Запрос пользователя на ввод данных

Человек, запускающий сценарий, увидит приглашение и введет ответ :

Использование аргументов командной строки

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

Различные способы создания циклов

Использование оператора case

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

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

Реакция на ошибки

Источник

Как написать сценарий линукс

Автор: Кузнецов Константин

Пишем скрипты в Linux (обучение на примерах)

Содержание:
1. Введение
2. Обучение написанию сценариев на внутреннем языке BASH (Перевод с англ.)
3. Используемая и рекомендуемая литература

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

Зачем нужны скрипты
Во-первых, администрирование linux-сервера в той или иной степени сводится к систематическому выполнению одних и тех же команд. Причем не обязательно, чтобы эти команды выполнял человек. Их можно запрограммировать на выполнение машиной.
Во-вторых, даже просто выполнение обычной задачи, которая (вдруг) составляет 20-1000… однообразных операций ГОРАЗДО проще реализовать в скрипте.

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

Как писать скрипт
В нашем случае скрипт будет представлять из себя текстовый файл с атрибутами выполнения. Если файл сценария начинается с последовательности #!, которая в мире UNIX называется sha-bang, то это указывает системе какой интерпретатор следует использовать для исполнения сценария. Если это трудно понять, то просто запомните, что все скрипты мы будем начинать писать именно со строчки #!/bin/bash или #!/bin/sh, а далее пойдут команды и комментарии к ним.

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

Какие скрипты могут нам понадобиться:

    устанавливающий правила файервола при загрузке системы.

    выполняющий backup настроек и данных.

    добавляющий почтовые ящики в почтовый сервер (точнее в базу mysql)

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

    отправляющий нам на почту информацию о том, что кто-то получил доступ к нашему серверу по ssh, время подключения и адрес клиента.

О методике написания скриптов
Создаем текстовый файл, редактируем его, устанавливаем права на выполнение, запускаем, смотрим ошибки, исправляем, запускаем, смотрим ошибки…
Когда все вылизано и работает правильно, ставим его в автозагрузку либо в планировщик на определенное время.

2. Обучение написанию сценариев на внутреннем языке BASH
оригинал: https://www.linuxconfig.org/Bash_scripting_Tutorial

Это руководство предполагает отсутствие предварительных знаний о методике написания сценариев (далее скриптов) с помощью внутреннего языка Bash. С помощью данного руководства вы обнаружите в скором времени, что написание скриптов очень простая задача. Давайте начнем наше обучение с простого сценария, выполняющего вывод строки «Hello World!» (в перев. с англ. — Всем привет!)

Читайте также:  Какие придаточные есть в русском языке

1. Сценарий «Всем привет»
Вот ваш первый пример bash-скрипта:

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

Запускаем скрипт на выполнение

2. Простой архивирующий bash-скрипт

3. Работа с переменными
В данном примере мы объявляем простую переменную и выводим её на экран с помощью команды echo

Наш архивирующий скрипт с переменными:

3.1 Глобальные и локальные переменные

4. Передаем аргументы в скрипт

5. Выполнение в скрипте команд оболочки

Как видим, во втором случае вывелась сама команда, а не результат её выполнения

6. Читаем пользовательский ввод (интерактивность)

7. Использование ловушки

Как видим, сочетание клавишь Ctrl-C не остановило выполнение скрипта.

8. Массивы
8.1 Объявляем простой массив

8.2 Заполняем массив значениями из файла

9. Условия «если-то-иначе»
9.1. Простое использование «если-иначе» условий
Обратите внимание на пробелы в квадратных скобках, без которых условие работать не будет.

9.2 Вложенные «если-иначе» условия

echo «You have chosen word: Bash»

Таким образом сначала тело цикла «while» выполняется, т.к. переменная choice изначально равна четырем. Потом читаем в неё пользовательский ввод, и если ввод не равен 1,2 или 3 то делаем нашу переменную снова равную 4, в связи с чем тело цикла повторяется (снова необходимо вводить 1,2 или 3).

10. Сравнения
10.1 Арифметические сравнения

10.2 Символьно-текстовые сравнения

11. Проверка файлов

12. Циклы
12.1. Цикл For

Запуск for-цикла из командной строки bash:

12.4. Циклы с неявными условиями
В следующем примере условием while-цикла является наличие стандартного ввода.
Тело цикла будет выполняться пока есть чему перенаправляться из стандартного вывода в команду read.

Источник

Titiaiev / bash-guide-1.md

Бесплатная книга-сайт на русском, полный гайд
Advanced Bash-Scripting Guide

BASH — Bourne-Again SHell (что может переводится как «перерожденный шел», или «Снова шел Борна(создатель sh)»), самый популярный командный интерпретатор в юниксоподобных системах, в особенности в GNU/Linux. Ниже приведу ряд встроенных команд, которые мы будем использовать для создания своих скриптов.

break выход из цикла for, while или until
continue выполнение следующей итерации цикла for, while или until
echo вывод аргументов, разделенных пробелами, на стандартное устройство вывода
exit выход из оболочки
export отмечает аргументы как переменные для передачи в дочерние процессы в среде
hash запоминает полные имена путей команд, указанных в качестве аргументов, чтобы не искать их при следующем обращении
kill посылает сигнал завершения процессу
pwd выводит текущий рабочий каталог
read читает строку из ввода оболочки и использует ее для присвоения значений указанным переменным.\
return заставляет функцию оболочки выйти с указанным значением
shift перемещает позиционные параметры налево
test вычисляет условное выражение
times выводит имя пользователя и системное время, использованное оболочкой и ее потомками
trap указывает команды, которые должны выполняться при получении оболочкой сигнала
unset вызывает уничтожение переменных оболочки
wait ждет выхода из дочернего процесса и сообщает выходное состояние.

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

Что необходимо знать с самого начала

в этой строке после #! указывается путь к bash-интерпретатору, поэтому если он у вас установлен в другом месте(где, вы можете узнать набрав whereis bash ) поменяйте её на ваш путь.

Переменные и параметры скрипта

Приведу как пример небольшой пример, который мы разберем:

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

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

Условные операторы, думаю, знакомы практически каждому, кто хоть раз пытался на чем-то писать программы. В bash условия пишутся след. образом (как обычно на примере):

#!/bin/bash
#в переменную source засовываем первый параметр скрипта
source=$1
#в переменную dest засовываем второй параметр скрипта
dest=$2

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

Структура if-then-else используется следующим образом:

для построения многоярусных условий вида:

для краткости и читаемости кода, можно использовать структуру:

Условия. Множественный выбор

Если необходимо сравнивать какоую-то одну переменную с большим количеством параметров, то целесообразней использовать оператор case.

esac #окончание оператора case.

После выбор цифры и нажатия Enter запуститься тот редактор, который вы выбрали(если конечно все пути указаны правильно, и у вас установлены эти редакторы 🙂 )

Прведу список логических операторв, которые используются для конструкции if-then-else-fi:

-z # строка пуста
-n # строка не пуста
=, (==) # строки равны
!= # строки неравны
-eq # равно
-ne # неравно
-lt,( # меньше
-le,( # меньше или равно
-gt,(>) #больше
-ge,(>=) #больше или равно
! #отрицание логического выражения
-a,(&&) #логическое «И»
-o,(||) # логическое «ИЛИ»

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

Оператор for-in предназначен для поочередного обращения к значениям перечисленным в списке. Каждое значение поочередно в списке присваивается переменной.
Синтаксис следующий:

Рассмотрим небольшой пример:

Цикл while сложнее цикла for-in и используется для повторения команд, пока какое-то выражение истинно( код возврата = 0).
Синтаксис оператора следующий:

Пример работы цикла рассмотрим на следующем примере:

А теперь результат работы скрипта:

Как видим цикл выполняется до тех пор, пока мы не введем что-то отличное от «yes». Между do и done можно описывать любые структуры, операторы и т.п., все они будут выполнятся в цикле.Но следует быть осторожным с этим циклом, если вы запустите на выполнение в нём какую-либо команду, без изменения переменной выражения, вы можете попасть в бесконечный цикл.

Рассмотрим еще один пример, я взял его из книги Advanced Bash Scripting. Уж очень он мне понравился :), но я его немного упростил. В этом примере мы познакомимся с еще одним типом циклов UNTIL-DO. Эта практически полный аналог цикла WHILE-DO, только выполняется пока какое-то выражение ложно.
Вот пример:

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

Ну вот, как видите ничего сложного, список математических операций стандартный:

+ — сложение
— — вычитание
* — умножение
/ — деление
** — возведение в степень
% — модуль(деление по модулю), остаток от деления
let позволяет использовать сокращения арифметических команд, тем самым сокращая кол-во используемых переменных. Например: a = a+b эквивалентно a +=b и т.д

Работа с внешними программами при написании shell-скриптов

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

Для начала немного полезной теории.

Если есть необходимость дописывать в файл(при использовании » > » он заменятеся), необходимо вместо » > » использовать » >> «

после просьбы sudo ввести пароль, он возьмется из файла my_password, как будто вы его ввели с клавиатуры.
Если необходимо записать в файл только ошибки, которые могли возникнуть при работе программы, то можно использовать:

символ » & » означает указатель на дескриптор 1(stdout)
(Поумолчанию stderr пишет на ту консоль, в котрой работает пользователь(вренее пишет на дисплей)).

Конвеер — очень мощный инструмент для работы с консолью Bash. Синтаксис простой:
команда1 | команда 2 — означает, что вывод команды 1 передастся на ввод команде 2
Конвееры можно группировать в цепочки и выводить с помощью перенаправления в файл, например:

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

1. Передача вывода в переменную.

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

Результат работы: qwerty

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

Источник

Приемы написания скриптов в Bash

Совет 1

Совет 2

Совет 3

Совет 4

Совет 5

Совет 6

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Bash-скрипты, часть 6: функции и разработка библиотек

Bash-скрипты: начало

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 46

Не знаю, откуда вы взяли совет 1. Я бы написал наоборот:

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

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

Нет. vlivyur привёл решение, которое, по его мнению должно было запретить запуск чего‐либо по нажатию в MC (для текущего каталога) (во всяком случае, я так понял).
Я указал, что данное решение также запретит использование всех подкаталогов, затем Frosty показал, как можно этого избежать.
Ваш комментарий к ответу Frosty был воспринят как попытка указать на лучший способ решения проблемы (никаких явных указаний, что вы хотите этим способом повредить систему в нём нет, а других причин иметь именно такой комментарий именно к тому ответу я не вижу).
Поэтому sledopit указал, что это просто усугубляет проблему.
Вы, очевидно, не поняли, что sledopit хотел этим сказать, так как указанное им поведение наблюдается при запуске от пользователя.
Поэтому я уточнил, о чём там идёт речь.

Теперь вы говорите, что кто‐то говорил о том, как повредить систему, хотя ни в каком из предшествовавших вашему комментариев это не предполагалось.

Да, упустил это, но смысл решения понятен.

Frosty, видимо, понял это так же и предложил «исправленный» вариант команды, которая гарантированно портит execution-биты во всех подкаталогах ниже текущего, а я, соответственно, добавил, что куда проще, если уж говорить о случайных командах, которые могут все испортить, попасться на рекурсивном chmod.

Как можно пытаться «решать» проблему того, что человек пользуется mc, работает под рутом и случайно может что-то запустить — я не знаю. Видимо, для начала отбирать у человека права и, возможно, mc.

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

С первым правилом не согласен.
В крайнем случае можно так:

а) скрипт без параметров должен ничего не делать, либо делать что-то с теми путями, которые в нём (или в файле конфига) hardcoded (а раз так, значит он настроен пользователем системы на эту систему и ничего плохого не случится)

И никаких проблем при случайном нажатии на скрипт в mc не будет.

Если Вам нужен скрипт который что-то спрашивает, может Вам стоит в сторону GUI приложений посмотреть?

Возможно первое правило действительно нуждается в лучшей формулировке. Да, у меня тоже не все скрипты просят подтверждения. Ключевые слова «выполняют действия» — это именно то, что Вы называете деструктивным поведением.

Зачем нужны скрипты, которые не выполняют действия?

То, что я называю «деструктивным поведением» — это поведение, в результате которого безвозвратно теряются данные. Это не bunzip file.bz2 / bzip2 file — оно обратимо. Это не загрузка скриншотов на Яндекс.Фотки, отмонтирование, убийство operapluginwrapper, печать файла как книги на принтере или даже удаление сокетов dtach (даже если всех, включая соответствующие рабочим процессам) (dtach — аналог screen, из которого выпилен весь функционал за исключением возможности работы после убийства эмулятора терминала/ssh сессии и возможности переприсоединения).

Я пока не нашел универсального способа именования скриптов… Поделитесь.

Я пользуюсь mc 12 часов в сутки. И он у меня по Enter не только запускает скрипты, но и открывает почти все файлы. Не говоря обо всех его остальных возможностях. Это такой удобный и естественный инструмент, что мне как-то даже нечего сказать по поводу «автодополнения в консоли».

Естественным он быть не может, равно как и консоль и вообще все интерфейсы.

Относительно удобства — опишите любой use‐case и я скажу, как это сделать быстрее в консоли с автодополнением. Единственный случай, когда mc является удобным — это когда я не помню, что находится в конкретном каталоге. Так как единственные каталоги, про которые я этого не помню — это то куда скачиваются torrent’ы, а все операции сводятся к изредка используемым aplayer /mnt/files/torrent/Series/Common\ series\ prefix\ \ *.mkv (можно и просто …/*.mkv, но в этом случае при случайном выходе из mplayer сложнее сказать, что хочешь смотреть все серии, начиная со, скажем, 15‐й. А так заменяется на ), то иметь mc ради такого случая мне кажется странным. Кроме того, мне не понятно, как в случае запуска с N‐й серии мне поможет mc.

Читайте также:  Лучший язык программирования для создания программ

Я бы сказал, что тут практически все советы — вредные:

В общем с «-e» нужно очень внимательно подходить к тому чего хочется достичь. Иногда лучше регулярно проверять код выхода чтобы выводить человеческие сообщения об ошибках, чем просто завершать скрипт по любому поводу.

Насчет правила написания «скриптов». Я бы сказал так, что «правила написания скриптов» НЕ должны особенно отличаться от «правил написания программ»:

2) Ваш скрипт/программма может произвести «деструктивное» действие? Обьект над которым проводиться это действие — должен задаваться исключительно в качестве параметра, и ни в коем случае, не «по умолчанию». Обратите внимание на то, как это работает: Например «недеструктивная» комманда ls имеет «обьект по умолчанию» — текущую директорию. А представьте какой «адский песец» был бы, если бы программа mkfs «по умолчанию» использовала бы, например /dev/sda1. Или rm безпараметров бы вычищал текущую директорию?

3) Для скрипта/программы exit-код обязателен! Можно даже без «детализации причин». Обязательное правило: Минимальная возвращаемая информация — это 0/1, сигнализирующая о том, что «да, запрашиваемое действие успешно выполнено» или «нет, запрашиваниемое действие не выполнено». Это даст возможность использовать ваш скрипт/программу из других скриптов/программ.

4) Для скриптов/программ имеющих возможность работать в пакетном режиме, должна быть возможность работы в полностью пакетном режиме. Т.е. НЕ надо настаивать на лишней интерактивности там, где она не является необходимой. Это к вопросу, по поводу «Вы уверенны [y/n]?». Самый лучший пример: программа rm, у которой есть ключ «-i» заставляющий спрашивать подтверждения длействия, а также ключ «-f» заставляющий ее продолжить пакетную работу даже если возникли проблемы с удалением конкретного файла. Если бы интерактивность rm была бы всегда, ее бы просто выкинули на помойку сразу после первой же необходимости прочистить директорию с несколькими тысячами файлов.

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

1. Unix никогда не скажет «пожалуйста». У этого есть причина. Покажите в багтрекере баша баг вроде «cd должен спрашивать подтверждения перед переходом в каталог». Написанные пользователями windows программы, ведущие диалог с пользователем, бесят хотя бы из-за сложности скриптования (пример — ntpasswd). Да, скрипты используются наравне со всеми UNIX-командами и точно так же могут быть в любом месте конвеера. Не заставляйте пользователей выкусывать бесполезный выхлоп. Мусорить \n в stderr тоже нехорошо.

3. Не прикасайтесь к /usr/bin руками без серьёзной причины. Там работает пакетный менеджер. Да и бэкапить отдельные файлы из него неудобно. Библиотеке функций место где-нибудь в (сюрприз)

, куда пользователь может писать. В произвольном дотфайле, включенном в

/.$SHELLrc, поскольку в повседневной работе (не все же пользуются mc) функции тоже нужны, не зря же их писали.

Скрипт — это программа, пусть и написанная для себя и для конкретной машины/группы машин. Не надо ненавидеть себя, ухудшая юзабилити. Хотя пользователям mc сойдёт.

Насчет Пункта 3. не все хабраюзеры знакомы «со стандартами», поэтому позволю себе «развернуть данный пункт»:

* /usr/bin — для тех программ, которые установленны из вашего дистрибутива. туда они ставятся, оттуда удаляются, там обновляются пакетным менеджером. И таки да, что-то самому туда класть — надо иметь серьезную причину.

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

* /usr/local/bin — программы, существующие/установленные/написанные для локально конкретной машины/группы машин. Все то, что не является частью дистрибутива, а установленно/написанно админом руками. Сами пакетные менеджеры дистрибутивов никогда туда ничего не кладут. Все что там есть — установил локально админ.

* /opt/[product-name]/bin — бинарники «больших» опциональных «программных продуктов». Если у вас такой массивный, тесно связанный программный продукт, то велкам туда.

P.S.#1: таки-да, некоторых товарищей, активно проталкивающих самые худшие практики из мира windows в мир unix, хочется пристрелить.
P.S.#2: насчет «mc юзеров» — мы же пониманием, что те mc юзеры о которых вы говорите, они же его просто «не умеют правильно готовить» (одни макроподстановки многого стоят, не говоря уже о прочей кастомизации)

Можно добавить папку в

/.$SHELLrc, можно просто в скрипте логина PATH=/home/vvzvlad/scripts;$PATH

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

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

/bin — в системные каталоги лучше не лезть — как пить дать забудете, а скопировав

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

Выкидываем bash, берем любой скриптовый язык типа перла, руби или питона. Можете считать это личным мнением, но не вижу смысла интенсивно использовать sh скрипты, когда есть более мощные (и, субъективно, с менее крышесносящим синтаксисом) языки типа перла, где в большинстве случаев написание скрипта сведется к написанию cli-интерфейса к какому-нибудь модулю с cpan.

Источник

Простые слова
Adblock
detector