Unix от юзера и до администратора
23 февраля 2004
Рубрика: Технологии.
Автор: Булат Урманчеев.
pic

Занятие первое — вводное

Идея распространения общеобразовательных учебных курсов прямо со страниц журнала принадлежит не мне, а ее общим автором является редакция журнала «InfoCOM.UZ». В данный момент журнал уже ведет переговоры с различными учебными заведениями республики с целью распространения нашего издания в системе общего и специального образования. Но переговоры — вопрос времени. Другое дело внутреннее содержание статей и материалов, которые должны соответствовать тому, чтобы журнал мог давать необходимую общеобразовательную нагрузку. Причем статьи эти должны не подменять учебных пособий по информатике, а нести гораздо большую информационную нагрузку, которая будет дополнительной помощью не только самим учащимся или их преподавателям, но и тем, кто уже связал свою профессиональную деятельность с освещаемыми журналом технологиями.

Серия учебных статей по современным технологиям начинается со знакомства с самой профессиональной операционной системой Unix. Причем знакомство это будет проходить от А и до системного администрирования. И любой желающий сможет ознакомиться с данной операционной системой буквально с нуля и, постепенно осваивая материал с каждой новой статьей, повышать свою квалификацию.
Биографию Unix я расписывать не буду, так как ее можно и в книжках почитать. Скажу лишь, что его датой рождения является 1969 год. Но в компьютерах все часы настроены так, чтобы считать время от 1 января 1970 года, то есть от официального дня рождения Unix, именуемого Epoch (Эпоха Unix). Сюда следует добавить, что Unix создавался профессионалами и для профессионалов. Операционная система Unix получила свое рождение в стенах компании «Bell Labs», причем не сразу, а став результатом нескольких последовательных, в том числе и некоммерческих проектов. И это неудивительно, ведь «Bell Labs» — не просто коммерческая организация, целью которой являются прибыли, а настоящая кузница не только высоких технологий, но и выдающихся личностей, причастных к этим самым технологиям, так как среди ее сотрудников можно назвать и отца — основателя информатики К. Шеннона, и еще 10 лауреатов Нобелевской премии. За время существования этой компании ее сотрудниками было запатентовано более 30 тысяч изобретений. Причем первый почин был сделан еще Александром Беллом — основателем компании и одним из изобретателей телефона. OS Unix — это всего лишь один из многочисленных очередных проектов «Bell Labs». Сам Unix написан на языке С, а потому легко переносим на любые вычислительные платформы, так как имеет возможность кросс-компиляции. То есть для его переноса необходимо взять любой рабочий компьютер, на котором уже есть любая реализация языка С и скомпилировать на нем транслятор языка «Small C» (упрощенный С), подставив в некоторые места ассемблерный код новой платформы. Таким образом, перенеся «Small C», мы уже можем работать на новом компьютере с этим, хотя и примитивным, но языком программирования, а значит, и скомпилировать на нем ядро OS Unix. Переносим туда образ ядра и запускаем. Вот и вся технология кросс-компиляции, если не считать еще написание драйверов, но это уже дело техники. Поэтому многие разработчики компьютерной техники в первую очередь устанавливают на своих аппаратных платформах Unix, а многие ничего другого устанавливать и не собираются.
Самое сложное при знакомстве с Unix — это узнать, с какой стороны к нему подходить. Но стоит только показать кому-либо этот подход, как его потом палкой не отгонишь и никакими Windows не заманишь. Почему? Да потому, что Unix — понятная и открытая система с такими возможностями, о которых даже знатоки только догадываются. И это правда, так как Unix досконально изучить невозможно, да и не нужно. Ведь в нем все сделано для профессионалов из огромного пространства областей практической деятельности, охватить которые даже взглядом невозможно, не говоря уже об элементарной компетенции во всех этих областях сразу. Плюс гибкость, то есть если что не слишком устраивает, то можно взять и просто переделать под свои интересы.
Подходить к Unix лучше всего через алфавитно-цифровую консоль. Или, как ее еще называют, терминал, то есть монитор и клавиатуру. Если вы начнете с графического интерфейса XWindow, то только заблудитесь. А заблудиться здесь несложно, так как пространство деятельности весьма обширное, а вариаций этих самых Xwindow столько, что никаких пальцев на всех конечностях даже у мутанта не хватит, чтобы, только загибая их, перечислить. Многим такой подход кажется странным, так как графический интерфейс представляется «неотъемлемой» частью современных технологий. Но это лишь заблуждение, распространяемое в том числе и не слишком компетентными нашими коллегами — журналистами. Когда дело касается профессионализма, то графический интерфейс — не помощник, а скорее — помеха. Да и зачем он нужен, если мы не собираемся изучать основы работы с графикой, будь она растровая, векторная, 3D или мультимедийная? Ведь для того, чтобы пользоваться возможностями Unix или администрировать данную ОС, вполне достаточно самых примитивных средств отображения информации. Тому есть свой резон. Во-первых, чтобы передавать команды с удаленного терминала, не надо инсталлировать сложные программы ремонтного доступа, а вполне подойдет любая примитивная терминалка. Во-вторых, нет ни одной графической реализации, которая в полной мере могла бы заменить, например, возможности одного только потокового редактора sed. В-третьих, передача информации в текстовом виде более компактна и менее ресурсоемка, нежели мышиная возня в графическом интерфейсе, не говоря уже о скорости. В-четвертых, когда мы говорим Unix, то подразумеваем майнфрейм (mainframe), когда говорим майнфрейм, то подразумеваем Unix.

pic

Вот на майнфрейме и задержимся немного. Предположим, что вы являетесь руководителем организации. Вполне естественно, что с учетом развития современных технологий приходится все время обновлять оргтехнику, причем довольно-таки кардинально. Берем элементарную ситуацию: некая организация имеет на своем материальном балансе то или иное количество морально устаревших компьютеров, принтеров и прочее. Необходимо при минимуме средств максимально приблизить ее возможности к современным технологиям. Чего тут думать, заявит читатель, надо отправиться в IT-компании, сделать заявки и по подготовленным проектам рассмотреть предложения. Из всех полученных таким образом проектов следует выбрать самый оптимальный. Нетрудно угадать, что будет в проекте. Это однозначно — списание старой оргтехники и закупка современной, включая прокладку сети с топологией, соответствующей архитектуре под управлением линейки серверов на базе MS NT, а также различные варианты подключения к Интернету, начиная от модемной связи и заканчивая оптоволоконным кабельным соединением. И это вполне понятно, так как проект в глазах IT-компании, естественно, подразумевает обратную задачу, то есть при максимуме средств, выжатых из клиента, приблизить его к современным технологиям, плюс привязать клиента к себе не только на время установки нового оборудования, но и на дальнейшее техническое обслуживание и обеспечение.
Что получается? То, что прежняя оргтехника подлежит списанию — это однозначно, так как она уже не вписывается в подобную модернизацию. Остальное уже идет в том направлении, что на каждое рабочее место устанавливается по современной персоналке, включая принтеры, сканеры, ксероксы, плоттеры и так далее. Все это завязывается в одну сеть и подключается к серверам. Сервера соединяют эту сеть с внешним миром посредством Интернета. Это только железо. Далее необходимо еще и программное обеспечение, то есть на каждую персоналку нужно посадить операционную систему и как минимум офисный пакет, не считая еще и специализированных программ. Естественно, что каждый компьютер в этом случае должен иметь соответствующий носитель информации приличного объема. Также программное обеспечение необходимо закупить и для серверов — операционную систему и пакеты различных серверных служб. И т.д. и т.п. Естественно, что если организация крупная, то такой проект еще и времени для реализации требует немалого. Предположим, что средств хватило, техника закуплена, сеть проложена, программное обеспечение запущено. Тут начинается иная проблематика, а именно организационная — мало все это установить и проинсталлировать, а надо еще и с учетом новой специфики запустить в делопроизводство. Тут-то и оказывается, что все не так, как хотелось. Старые сотрудники привыкли к старым программам и из-под 32-битных Windows запускают Lexicon для MS-DOS, чтобы подготовить документацию. Новые сотрудники освоились быстро и даже слишком, так как компьютерная сеть используется ими для самых современных игр, а принтеры и плоттеры печатают различные плакатики и прочую мишуру. Интернет также используется для личной переписки и закачки не слишком обремененных одеждой девиц и т.д. Где Windows, там и компьютерные вирусы, а это опять же проблемы, причем эпидемиологические по последствиям. Плюс ко всему различные казусы, типа сотрудник заболел или опоздал, а в его запертом кабинете хаб не включен, и целый этаж оказался изолированным от сети, не говоря уже о том, что новая оргтехника имеет тоже склонность к поломкам, а это опять же простои, даже несмотря на то, что все оборудование ремонтируется по гарантийным обязательствам. И за всем этим не уследишь, а когда уследишь, то уже слишком поздно.

pic

Это происходит, как правило, у нас. А как, например, в США. Смотрим американские фильмы и удивляемся тому, что Windowsом там и не пахнет. Может быть, Голливуд имеет обиду на Билли Гейтса? На самом деле, все гораздо проще. Стоит крупная организация, а в ее подвале с каких-нибудь 60-х годов прошлого столетия до сих пор пыхтит эдакая PDP-11, если не 10-я. У каждого сотрудника на рабочем месте терминал. Смотрим, что на этом терминале. И видим, что это совсем не рабочий стол Windows, к которому мы так уже привыкли, а лишь зеленые буквы и цифры бегают по темному экрану. Причем системного блока нигде поблизости не видно, а от монитора идут проводки в короба. Есть клавиатура, мышки нет. Заходим в другой отдел. Здесь уже работают с графикой, и терминалы соответственно графические, помимо клавиатуры, есть еще и мышки, но логотипа Microsoft в виде искривленной форточки опять же не видно — станции «Silicon Graphics» работают под Unix. Графические терминалы — это опять же не компьютеры, а лишь мониторы с встроенными видеочипами только для вывода информации, так как обработка графических изображений полностью выполняется ЭВМ, к которой данные терминалы подключаются. Идем к полиграфистам. Здесь можно уже встретить персоналку, но это не Intel и не Athlon, а чаще всего MAC, причем не с родной MacOS, а опять же под Unix. Ладно, если уж не на рабочем месте, то наверняка дома американцы используют Windows, чтобы отдохнуть от Unix. Не повезло — здесь играют в игры с помощью приставок к телевизору. Можно долго ходить и искать, где же на родине Windows его можно найти. И наконец натыкаемся. Но что это? Знакомая русская речь без акцента. Ну, конечно же, это наши бывшие соотечественники или еще не бывшие, а лишь приехавшие подзаработать.
Почему американцы так не любят Windows? Дело в том, что они вообще не понимают, что такое любить ту или иную операционную систему или отдавать предпочтение различным языкам программирования. Они на все смотрят с практической точки зрения, которая чаще всего является экономической. Если предложить им еще что-либо подешевле, то они запросто перейдут на новую платформу. И если руководителя тамошней компании или даже фирмочки спросить, почему он не выкинет на свалку давно устаревшую малую или большую ЭВМ, которые у нас уже давно разобрали на драгоценные металлы, то он лишь пожмет плечами.

— А зачем? Она ведь работает хорошо.

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

1. Операционка Linux Red Hat 6.2
2. Процессор Intel 386 SX
3. ОЗУ 8 Мегабайт
4. Жесткий диск объемом 1 Гигабайт

Иметь отдельный процессор на каждом рабочем месте или несколько высокопроизводительных процессоров в одном корпусе на всех? Когда одна ЭВМ для всех, то это и есть майнфрейм. То есть для майнфрейма нет необходимости, чтобы подключаемые к нему терминалы имели хоть какую-либо вычислительную мощность, кроме той, которой достаточно лишь для ввода и вывода информации. Здесь каждому пользователю выделены не только файловые, но и вычислительные ресурсы. То есть один компьютер, один экземпляр программного обеспечения, но пользователей много. Второе преимущество майнфрейма в том, что он меньше всего простаивает. Почему? Например, если у меня персоналка, то, уйдя на «перекур», я за ней уже не работаю, и ее вычислительные способности в это время не используются. Если мы имеем дело с майнфреймом, то здесь одна машина на всех и пока одни заняты иными делами, задачи других используют процессорные ресурсы. Простои сводятся к минимуму.

pic

Дополнительная экономия и за счет терминалов. Если пользователи должны обрабатывать лишь алфавитно-цифровую информацию, то терминал должен быть соответствующий. Иногда даже можно встретить не терминал, а телетайп, то есть принтер как устройство вывода и клавиатура. А следовательно, при таких «возможностях» на рабочих местах в «Quake» уже с кем-либо по сетке не порежешься. Для американцев это вполне понятно, так как у них оплата почасовая, и платить за то, что сотруднику надо готовиться к турниру по компьютерным играм, работодатель из своего кармана не намерен. Следующая экономия в модернизации. Если нужно приблизиться к современным технологиям, пожалуйста, берем оргтехнику и подключаем ее к майнфрейму. Ни о каких массовых списаниях старой техники, если она еще в рабочем состоянии, и речи быть не может. Плюс экономия на организационных ресурсах, если модернизация идет постепенно, то, естественно, ее процесс не сказывается на том, что приходится менять организационные планы. Каждому сотруднику выделены определенные ресурсы и задачи. Те, кто работают над совместными проектами, объединены в группы с общим доступом к ресурсам таких проектов. Причем у каждого свои ресурсы и своя зона ответственности, поэтому есть кому отвечать, а следовательно, и с кого спросить, если что не так. Далее экономия на ремонте. Большие, малые ЭВМ и прочие станции на RISC-процессорах имеют предусмотренные возможности для ремонта и профилактических работ без остановки компьютера. Это так называемая горячая замена. То есть если устройство вышло из строя, то его функции временно берут на себя другие резервные устройства. Поэтому если какой-либо из винчестеров начал сыпаться, то это не повод для того, чтобы хвататься за голову или низменные места, а лишь поступит сообщение на терминал дежурного системного администратора. А тот, в свою очередь, сообщит аппаратчикам, которые уже без всякой суеты, так как техника все равно работает, устранят на ходу неисправность. Описывать преимущества майнфреймов можно очень долго. Основное их достоинство — это экономия денежных средств. Американцы не потому живут в достатке, что ведут слишком роскошную жизнь, а как раз только благодаря экономии. Следует лишь сказать, что технология клиент-сервер — это догоняющая технология, так как любой майнфрейм уже имеет эту технологию на борту, а клиент-сервер — это еще не майнфрейм по своим функциональным возможностям, а лишь попытка эмуляции.
Начинать знакомство с Unix надо с простейших базовых понятий, без знания которых узнать о чем-либо более сложном — попасть впросак. Базовым понятием в Unix является поток информации stream. Вся система устроена так, что представляет собой сплошные взаимодействия потоков. Вы нажали кнопку клавиатуры, и символы ушли в консольный поток. Буквы или цифры появились на экране — это тоже потоки. Для системы не существует ни файлов, ни устройств, ни даже процессов, поскольку она видит потоки и оперирует этими самыми потоками. Причем потоки существуют в двух видах:

1. Потоки ввода — вывода информации содержат в себе информационные данные.

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

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

# cat soundfile.wav > /dev/sound

Что я сделал? Создал процесс cat, который должен принять информацию из файлового потока soundfile.wav, и перенаправил его поток вывода с помощью символа «>» прямо во входной поток звуковой карты. Точно так же, если мне нужно распечатать информацию, то я должен ее перенаправить в поток принтера. А если захочу работать с модемом, то соответственно без всякой терминальной программы могу напрямую соединиться с потоками COM-порта, на котором сидит модем, принимать и передавать информацию. То есть по сути работа в Unix — это лишь управление потоками. В этом-то и заключается вся гибкость и простота. В других операционках все более жестко, то есть там необходимо иметь какую-либо программу, которая будет управлять потоками, и только так, как ее задал программист. Я не говорю, что создать управление потоками с помощью многих языков программирования — это еще надо уметь сделать. Здесь же я сам себе хозяин: что хочу, то и вытворяю, и никакого постороннего программиста мне уже не нужно.

pic

С потоками немного разобрались, теперь пойдем дальше. Попробуем зайти в Unix через терминал. Первое, что нам встретится, это краткое сообщение о том, с какой версией мы имеем дело и просьба ввести Login. Login — это идентификатор пользователя, причем у каждого пользователя он свой. К логину прилагается еще и пароль, который также следует предъявить при входе в систему. Таким образом на входе нас встречает процесс *getty секюрити, следящий за проходной. Он и просит назваться. После чего проверит в списке /etc/passwd — есть ли там такой логин и соответствует ли пароль действительности, и, только убедившись, что мы не злоумышленники, пропускает в систему, причем не куда попало, а строго в определенное место, заведенное для каждого пользователя, т.е. его личную домашнюю директорию. После чего опять же по записи из /etc/passwd подключает нас сразу же к средству коммуникации — к какому-нибудь интерпретатору shell, с помощью которого мы уже посредством консоли можем оперировать потоками и общаться как с самой системой, так и с другими пользователями. Надо добавить, что *getty стоит только на входах, которых здесь множество, и отвечает только за них, так как мы можем зайти через любой виртуальный терминал непосредственно с консоли самого компьютера, на котором запущен Unix, либо с любого иного физического терминала, подключенного к нему, либо через удаленный доступ с любого другого компьютера, подключенного через сеть к данному. Причем, если мы заходим не с того входа, с которого нам разрешено, то *getty может и не пустить, не только простого пользователя, но даже и системного администратора.
После того, как мы прошли в систему, можно и оглядеться. Для этого запустим процесс:

# pwd,

который нам выдаст в консольный поток, что-то вроде:

/home/yury

Это путь к директории, в которой мы в данный момент находимся. Настало время поговорить о файловой системе Unix. На самом деле, как мы уже знаем, Unix — это потоковая система. Эта гибкость позволяет подключать к потокам ввода-вывода любую файловую систему, причем не столь важно, где она будет размещена физически — на жестком диске компьютера, на котором загружен сам Unix, или удаленном любом другом компьютере, который подключен через сеть к нашему (бездисковые станции) либо в виртуальном пространстве ОЗУ. В общем, вариантов очень много, чтобы их все перечислить. Причем сама файловая система не обязательно должна быть родной, т.е. Unixовой, а можно взять любую, например FAT32 из Windows. Важно, чтобы она была виртуальная или физическая. Также следует добавить и о директориях. Директории в Unix и в Windows — это небо и земля, т.е. совершенно разные вещи. В Windows мы лишь имеем возможность расположить внутри одной директории другие поддиректории и файлы. В Unix, помимо этого, еще директорией может быть все, что угодно, например другая файловая система, раздел диска или упорядоченные в каталоге и выполняющиеся системные процессы, представленные в виде файловых потоков, или файловая структура сменного накопителя информации и т.д.
Важно запомнить то, что файловая система Unix сборная, и потому здесь нет логических дисков, как, например, в MS-DOS или Windows. Поэтому все пути начинаются с root (англ. — корень), который обозначается как «/». От корня идут ветви в виде каталогов, каждый из которых имеет имя и свой корень, обозначаемый также символом «/». Поэтому когда мы видим что-либо вроде

/home/yury,

то это означает, что мы находимся, начиная от root, в поддиректории home и ее поддиректории yury. Попробуем попутешествовать. Для этого нам нужно запустить процесс cd (change directory — сменить директорию). Например, так:

# cd /,

что означает выйти в корневую директорию.
Проверим.

# pwd
/

Ну, а если нам необходимо вернуться назад, в свою домашнюю директорию? Для этого вовсе не обязательно набирать «cd /home/yury», поскольку есть специальное сокращение «~» (тильда), которое в путевых именах и означает домашний каталог текущего пользователя, поэтому сокращенно возвратимся назад и сразу же вызовем процесс pwd, чтобы узнать, куда мы попали

# cd ~/;pwd
/home/yury

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

# cd ../;pwd
/home

Сокращение «..» позволяет нам указать, что мы хотим выйти из данной директории на один уровень выше, в противном случае нам пришлось бы писать полный путь, т.е. «cd /home». В данном случае это некритично, но если бы мы забрались поглубже, то пришлось бы заниматься очень длинной писаниной. Также, чтобы сократить процесс написания команд, проще всего пользоваться буфером команд, в котором все предыдущие набранные нами команды сохраняются. Для этого нажимаем клавиатурную стрелку вверх и видим на экране:

# cd ../;pwd

еще вверх и:

# cd ~/;pwd

а если вниз, то:

# cd ../;pwd

Таким образом, не обязательно набирать заново команды, если мы их уже набирали до этого, а лишь с помощью стрелочек можно повторно вывести их. Теперь достаточно будет только нажать Enter, и заданные процессы запустятся на выполнение, так, будто бы мы их набирали вручную. Если команда нас не устраивает, то ее можно подредактировать, т.е. с помощью стрелочек «Вправо» и «Влево» перемещать курсор и, нажимая клавиши, вводить другие символы в позицию курсора или удалять с помощью клавиши «BackSpace».
Попробуем подредактировать наши процессы до такого вот вида.

# cd ../home/../etc;pwd
/etc

Т.е. мы сначала вышли на уровень выше в root, потом опять зашли в /home, потом опять поднялись в root, а оттуда уже перешли в /etc. Своего рода совершили эдакое путешествие, причем еще и петляя. Это вовсе не запрещено синтаксисом. Но давайте попробуем зайти в другое место, например в гости к администратору. Его подкаталог не располагается в /home, а имеется отдельный кабинет в /root

# cd /root;pwd
Directory /root — Access denied
/etc

Оказывается, нас туда не пустили, и мы оказались там же, откуда пытались выйти. Чтобы убедиться окончательно, также «попробуем совершить» деструктивное действие, например удалить системный файл:

# rm passwd;ls passwd
File /etc/passwd — Access denied
passwd

Что означает, rm — удалить файл в текущей директории с именем passwd и ls — вывести на консоль имя этого файла, если он существует, или, в противном случае, сообщение об отсутствии. Опять же мы не смогли «наломать дров» и доступ к деструктивным действиям был пресечен на корню. Значит, мы не имеем возможности заходить туда, куда нас не приглашали, и вносить изменения и дополнения в те ресурсы, в которые нас не просили. Почему так происходит?
После того, как *getty пропустил нас в систему, он запустил процесс shell с нашими привилегиями и передал ему наши консольные потоки. На самом деле мы ничего не можем выполнять, а лишь передаем указания для shell, который действует от нашего имени и передает нам на консоль сообщения от системы. Shell может попытаться от нашего имени запустить и другие процессы, но при этом соблюдается правило, согласно которому процесс может быть запущен опять же от нашего имени и с привилегиями, не превышающими наш уровень.
Настало время поговорить о shell. Shell — это не просто интерпретатор команд, как, например, command.com в MS-DOS. Это язык программирования высокого уровня со всеми присущими таким языкам возможностями, или условными и безусловными переходами, циклами и т.д. Но почему бы нельзя было использовать какой-либо язык программирования в качестве shell? Потому что в основе своей языки программирования не диалоговые, за исключением некоторых, как правило, имеющих интерфейс в виде польской записи. Чтобы выполнить команды какого-либо языка программирования, необходимо сначала составить программу, записать ее в файл и, вызвав процесс интерпретации или компиляции, выполнить. Здесь слишком много действий. Диалоговые языки позволяют все это делать, что называется, «на лету». Для этого диалоговый язык должен запустить редактор (с ним мы уже встречались, когда редактировали предыдущие команды) и по мере ввода команд сразу же их выполнять, выводя результаты на консоль. Плюс ко всему мы имеем возможность и программирования, как в обычных языках, т.е. открыть какой-либо файл, записать в него все команды по порядку и передать его shell на выполнение. Такой файл уже называется скриптом. Многие команды shell — это скрипты, написанные на самом shell. Это очень удобно, поскольку наиболее часто повторяющиеся действия не нужно каждый раз вводить с консоли. Любая shell-команда всегда начинается с имени процесса, который совпадает с именем файла, содержащего программу или скрипт этой команды. После команды идут аргументы, разделяемые пробелами, т.е. параметры, которые мы хотим ей передать. Если мы хотим выполнить последовательно несколько команд в одной строке, то их следует написать друг за другом, разделив точкой с запятой. Конец строки означает, что команда готова и shell должен попытаться ее выполнить. Почему только попытаться, мы уже знаем, что не все, что нам хочется, будет выполнено, а лишь то, что дозволено.

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

Команды вывода потоков.

cat — это не просто вывести на консоль содержимое потока. Я не пишу «файлового», поскольку потоком может быть не только файл, но все что угодно, например устройство ввода — вывода или даже запущенный процесс. cat может иметь много аргументов для передачи имен потоков. Сколько потоков задано и с какой последовательности, столько и в такой последовательности данная команда выведет на консольный поток или в тот, который мы переправим, т.е. команда контеканации (объединения) информации из разных потоков в один поток. Если аргументы не заданы, то информация будет выводиться с консоли. Если нам нужно создать какой-либо файл, то нет необходимости запускать текстовый редактор, а лишь запустить команду:

#cat > filename

и, пользуясь редактором shell, набить нужную информацию. По окончании ввода лишь нажать Ctrl+D
Помимо команды cat, есть еще три схожие команды:

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

pic

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

# tail f streamname,

то будет выводить информацию из потока streamname систематически, по мере обновления. Это очень удобно, когда нужно все время следить за потоком.
more — то же самое, что и cat, но если поток слишком длинный, чтобы информация уместилась на экране, то по мере заполнения экрана вывод будет приостановлен и more будет ждать продолжения. Если нажать Enter, то на консоль будет выведена следующая страница информации, если пробел — то строка.

Ну и наконец команды управления потоками файловой системы:

pwd — вывести полный путь к текущей директории, в которой мы сейчас находимся. Если имя файла, набранного в команде, не содержит полного пути от root, то оно считается от текущей директории, и shell автоматически прибавляет к нему пути, как в pwd. Эта команда не имеет аргументов, так как она однозначна.
cd — сменить текущую директорию. В качестве аргумента задается путь до директории, в которой собираемся работать.

ls — вывести на консоль имена файлов и поддиректорий, указанный в качестве аргумента. Если аргумент не указан, то по умолчанию выводятся имена файлов и поддиректорий текущей директории.

Например:
# ls /etc

Images ftpusers lpc rc.new shells
adm getty magic rc0.d startcons
bcheckrc gettydefs motd rc1.d swapoff
brc group mount rc2.d swapon
brc~ inet mtab rc3.d syslog.conf
csh.cshrc init mtools rc4.d syslog.pid
csh.login init.d pac rc5.d syslogd.reload
default initrunlvl passwd rmt termcap
disktab inittab printcap rpc umount
fdprm inittab.old profile rpcinfo update
fstab issue psdatabase securetty utmp
ftpaccess lilo rc services wtmp

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

rmdir — удалить директорию. В качестве аргумента указываются путь и имя создаваемой директории. Следует заметить, что команда по умолчанию удаляет лишь пустые директории, и если права на удаление разрешены, то еще и дополнительно просит подтвердить удаление.

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

Есть еще одна полезная команда.
man — вывести на консоль справочную информацию по команде shell, заданной в качестве аргумента. Все дело в том, что различные команды от версии к версии Unix могут иметь различные параметры, которые расширяют их возможности. Поэтому лучше всего, если возникли какие вопросы, обратиться к man. Вы убедитесь в том, что если бы я расписал все параметры хотя бы одной из вышеприведенных команд, то это бы заняло гораздо больше места, нежели данная статья. Поэтому обучение Unix всегда проводится в таком ключе, что пользователя лишь вкратце знакомят с командой или процессом, которые могут помочь ему выполнить какие-либо операции, а далее он должен самостоятельно и более детально ознакомиться с ней посредством справочной информации из man, readme, HOWTO и т.д. Поэтому довольно-таки часто вместо ответа просят читать HOWTO, при этом вежливо указывая, в каком конкретно месте. С другой стороны, это не самое удобное средство для ознакомления с Unix, так как многие справочные руководства рассчитаны на пользователя, имеющего некоторую подготовку. Поэтому цель данной статьи и других статей — ознакомить с тем базовым минимумом, который необходим для начала самостоятельной работы в Unix.

pic
Orphus system
В Telegram
В Одноклассники
ВКонтакте