Мендель Купер - Искусство программирования на языке сценариев командной оболочки

H --> G

Диграмма "SE" соответствует 1-му определению.

C O D E S (Строка содержит оба символа "S" и "E")

S --> C (замена на первый символ в строке ключа)

E --> S

Дешифрация выполняется обратной процедурой, для случаев 1 и 2 -- замена символом стоящим левее/выше. Для случая 3 -- аналогично шифрации, т.е. заменяется символом из соседнего, по горизонтали, угла. Helen Fouche Gaines, в своей классической работе "Elementary Cryptoanalysis" (1939), приводит подробное описание алгоритма Playfair и методы его реализации.

Этот сценарий должен иметь три основных раздела

I. Генерация "ключевой матрицы", основывающейся на слове, которое вводит пользователь.

II. Шифрование "плоского" текста сообщения.

III. Дешифрование зашифрованного текста.

Широкое применение, в этом сценарии, найдут массивы и функции.

--

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

Приложение J. Авторские права

Авторские права на книгу "Advanced Bash-Scripting Guide", принадлежат Менделю Куперу (Mendel Cooper). Этот документ может распространяться исключительно на условиях Open Publication License (версия 1.0 или выше), http://www.opencontent.org/openpub/. Соблюдение следующих пунктов лицензии обязательно.

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

2. Запрещено распространение твердых (бумажных) копий книги, или ее производных, без явного согласия держателя прав.

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

1. Некоммерческих организаций, таких как Linux Documentation Project и Sunsite.

2. Не "запятнавших" себя дистрибутивостроителей Linux, таких как Debian, Red Hat, Mandrake и других.

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

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

Права на коммерческое распространение книги могут быть получены у автора.

Автор произвел этот документ в соответствии с буквой и духом LDP Manifesto.

Hyun Jin Cha завершил перевод на Корейский язык версию 1.0.11 этой книги. Переводы на Испанский, Португальский, Французский, Немецкий, Итальянский и Китайский языки находятся на стадии реализации. Если вы изъявите желание перевести этот документ на другой язык, то можете свободно выполнить этот перевод, основываясь на условиях, заявленных выше. В этом случае, автор хотел бы, чтобы его поставили в известность.

Примечания

1

Их так же называют встроенными конструкциями языка командной оболочки shell.

2

Многие особенности ksh88 и даже ksh93 перекочевали в Bash.

3

В соответствии с соглашениями, имена файлов с shell-скриптами, такими как Bourne shell и совместимыми, имеют расширение .sh. Все стартовые скрипты, которые вы найдете в /etc/rc.d, следуют этому соглашению.

4

Некоторые разновидности UNIX (основанные на 4.2BSD) требуют, чтобы эта последовательность состояла из 4-х байт, за счет добавления пробела после !, #! /bin/sh.

5

В shell-скриптах последовательность #! должна стоять самой первой и задает интерпретатор (sh или bash). Интерпретатор, в свою очередь, воспринимает эту строку как комментарий, поскольку она начинается с символа #.

Если в сценарии имеются еще такие же строки, то они воспринимаются как обычный комментарий.

#!/bin/bash

echo "Первая часть сценария."

a=1

#!/bin/bash

# Это *НЕ* означает запуск нового сценария.

echo "Вторая часть сценария."

echo $a # Значение переменной $a осталось равно 1.

6

Эта особенность позволяет использовать различные хитрости.

#!/bin/rm

# Самоуничтожающийся сценарий.

# Этот скрипт ничего не делает -- только уничтожает себя.

WHATEVER=65

echo "Эта строка никогда не будет напечатана."

exit $WHATEVER # Не имеет смысла, поскольку работа сценария завершается не здесь.

Попробуйте запустить файл README с сигнатурой #!/bin/more (предварительно не забудьте сделать его исполняемым).

7

Portable Operating System Interface, попытка стандартизации UNIX-подобных операционных систем.

8

Внимание: вызов Bash-скрипта с помощью команды sh scriptname отключает специфичные для Bash расширения, что может привести к появлению ошибки и аварийному завершению работы сценария.

9

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

10

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

11

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

12

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

ls | { read firstline; read secondline; }

# Ошибка! Вложенный блок будет запущен в дочернем процессе,

# таким образом, вывод команды "ls" не может быть записан в переменные

# находящиеся внутри блока.

echo "Первая строка: $firstline; вторая строка: $secondline" # Не работает!

# Спасибо S.C.

13

Аргумент $0 устанавливается вызывающим процессом. В соответствии с соглашениями, этот параметр содержит имя файла скрипта. См. страницы руководства для execv (man execv).

14

Символ "!", помещенный в двойные кавычки, порождает сообщение об ошибке, если команда вводится с командной строки. Вероятно это связано с тем, что этот символ интерпретируется как попытка обращения к истории команд. Однако внутри сценариев такой прием проблем не вызывает.

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

bash$ echo hello!

hello!

bash$ echo "hello!"

hello!

bash$ echo -e xty

xty

bash$ echo -e "xty"

x y

(Спасибо Wayne Pollock за пояснения.)

15

"Разбиение на слова", в данном случае это означает разделение строки символов на некоторое число аргументов.

16

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

17

В современных UNIX-системах, "sticky bit" больше не используется для файлов, только для каталогов.

18

Как указывает S.C., даже заключение строки в кавычки, при построении сложных условий проверки, может оказаться недостаточным. [ -n "$string" -o "$a" = "$b" ] в некоторых версиях Bash такая проверка может вызвать сообщение об ошибке, если строка $string пустая. Безопаснее, в смысле отказоустойчивости, было бы добавить какой-либо символ к, возможно пустой, строке: [ "x$string" != x -o "x$a" = "x$b" ] (символ "x" не учитывается).

19

PID текущего процесса хранится в переменной $$.

20

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

21

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