Редактирование: UNИX, весна 2008, 02 лекция (от 20 февраля)

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

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

Но эта не главная задача. Главная задача: способ упр. компьютером позволит решать задачи, если они не решены. Идея в том, что компьютер предс-ть. инстр. для решения частых задач и способ комбинир. этих задач. Лектор говорит таким способом, чтобы не говорить, что мы программируем, тем не менее, другого способа нет, потому что другие способы --- выбор и конструирование из готовых решений.

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

Первая концепция:

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

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

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

* Не требование, а некое предположение. Пусть задачу мы поставили, попробуем наметить пути решения. Попробуем заглянуть на пункты построение решений и воспроизводимость. Давайте в пункт "управление": это взаимодействие компьютера и человека. Мы говорим о чём: мы сами управляем компьютером. И когда лектор говорит про управление, он говорит про то, что придёт он и будет имеющимися у него средствами взаимодействовать с компьютером. Отсюда требование, какими мы будем пользоваться каналами данных. Есть человек, существо с ограниченными каналами данным и с 5 чувствами. Если конкрет. вопрос, и понять, как орг. взаимод., то выяснится, что не так уж много способов орг. взаимод., как им командовать. Мы должны команды поставлять, а он их --- интерпретировать. И вводится допущение, что команда это текст. Это связано вот с чем: связано с решением двух след. наших задач: постр. и формализ. решений. На сегодняшний день мы просто идём к этому, на сегодняшний день ничего, кроме прогр., не придумано. Можно конечно обойтись без предолож, но постр. будет несколько другим. Чёткую и однознач. команду можно представить в виде текста. Никакого другого метода, как лектору кажется, не существует. В случае, когда вып. функций мало, когда каждому элементу упр. обозн. отдельное действие, если функций много, то мы получаем беск. много эл-тов упр, и надо как-то их конструировать, естественным образом это текст. Сейчас практически единственным способом является ввод по клавиатуре. А что касается поиска этого текста среди вариантов, то увидим, что этот текст используется. Команда --- это то, что дают. Основываясь на этом допущении, сделаем ещё ряд допущений.

Утвержд. 3: более строгое. Данные --- текст. Тут надо говорить, что такое текст. Надо дать некоторое опред. Текст: послед. символом, которые человек может прочитать глазами и понять. Смысл третьего утвержд: раз взаимод. осущ. текстовым способом, то и данные должны иметь тестовую форму. В том случае, когда картинки имеют содерж. знач, то неплохо и её выводить в текстовом виде.

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

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

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

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

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

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

Пример: попробовать написать программу, которая деалет ls | wc. Что делает эта команда: ls выдаёт список файлов, а wc считает количество строк, слов и символов в выдаче.

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

... и Интерфейсом терминальным, который предст. собой матрицу знакомест. Вопрос: мы вроде только что договорились, что наше терм. устройство умеет передавать байты, то есть, что это точка, а не матрица. Мы ничего не говорили про координаты. Как нам теперь от этого избавиться: избавиться можно, введя две хитрых сущности: первая сущность называется курсор. Что такое курсор: это индикатор того места, куда введётся символ. Второе: помимо наличия курсора, договариваемся, как некоторые символы являются упр для компьютера, так и некоторые выводимые символы управляют терминалом. То есть, есть символы двух родов: управляют компьютером и терминалом. Например, перевод строки он не символ, он переводит строку. Существуют гораздо более хитрые символы: переместить курсор в координаты 20,10. Зачем это нужно: устройство продолжает оставаться тупым. Тем самым, вводя понятие упр. символов терминала, мы избегаем дополнительных апп. ухищрений за искл. того, что терминал должен уметь распознавать символы. Но поскольку байтов разных мало, то есть управляющие последовательности. Есть специальный символ "начало упр. посл.", а за ним могут идти обыкновенные символы, но они интерп. как упр. послед. И вывод упр. последовательности приведёт, например, к изменению цвета или к перемещению курсора. Таких последовательностей чёртова прорва. Хуже всего, что за время сущ. терминалов их накопилось несколько сотен, и в каждом из них упр. посл. разные. Для того, чтобы этим как-то управлять, есть две БД терминалов, termcap и terminfo, в них описаны всевозможные функции терминалов, и какие можно выполнять дейтсвия. Кроме того, у термкапа есть язык программирования свой. Для того, чтобы посмотреть, что умеет конкретно ваш терминал, есть infocmp ,tset. Для того, что бы непоср. в шелле спозиц. курсор, то есть tput, после которого идёт termnfo/termcap capability. Терминал определён в $TERM. Для использования этого в программировании есть библиотека ncurses.