Время написания: февраль 2008
Как я написал в одном комментарии:
если не хотите знать про коммандную строку, то в линуксе вам делать нечего. Будет вам та же винда, только вместо одних проблем получите другие...
--comment605950
С другой стороны, как раз в shell заключается одно из кардинальных отличий Unix-систем, то, что делает эти системы открытыми...
В чем же основные особенности Unix shell, которых нет в Windows?
- Весь процесс конфигурации и администрирования Unix построен на работе с текстовыми файлами. Shell — это полноценный язык программирования, заточенный для манипуляции строками и работы с тектсовыми файлами. К тому же, именно как расширение возможностей shell по обработке строк и возник Великий язык PERL!.
- Благодаря п.1 shell — это отличный инструмент для постепенного изучения самой операционной системы.
- Наличие shell способствует реализации важного принципа создания любых программ:
Если это простая программа, которая предназначена для выполнения ограниченного числа операций, ее нужно реализовывать как набор команд, родных для платформы, на которой она работает (как правило, платформой является ОС). Если же имеем дело со сложной интерактивной программой с потенциально неограниченным набором операций — ее нужно реализовывать как язык опять же на родном для платформы носителе (сейчас наиболее родным и удобным носителем при взаимодействии с компьютерами все же является текст, а не звук, графика или что-либо еще).
Примерами 1-го и 2-го подхода могу служить tcpdump, реализованный полностью в текстовом режиме, над котором не представляет труда надстроить интерфейс (по сути, Ethereal — и есть подобный интерфейс), и emacs — самый расширяемый текстовый редактор.
В этом проявляется основное отличие философии Unix и Windows: в Win интерфейс програм по умолчанию делается на графическом языке, из-за чего программы практически невозможно сопрягать или строить на их основе новые. Потому что для этого нет поддержки на уровне ОС. И для того, чтобы сделать программы расширяемыми, все равно приходится использовать текст (пример — тот же VBA в Word и Excel). - Автодополнение команд и, что самое главное, путей. Трудно даже представить, сколько времени и сил экономит эта небольшая возможность!
- Полный набор утилит для всех возможных задач администрирования.
Стоит также перечислить утилиты shell, которые обязательно нужно использовать в повседневной работе с системой:
- man — это справка по ОС, которая включает не только описание работы всех команд, но также и что должно быть в большинстве из конфигурационных файлов, а также много другой полезной информации;
- less — просмотр текстовых файлов;
- grep (программистов, не знающих о grep, не берут на работу в Amazon.com :);
- locate — быстрый поиск файлов.
а еще можно вспомнить группы утилит, использование которых намного удобнее и эффективнее их графических аналогов:
- настройки сети (позаимствованные Windows);
- управления пакетами;
- управления пользователями;
- монтирования томов...
Можно только повториться, что для тех, кто не хочет работать в shell, Linux или другая Unix-based ОС — во многом такая же неудобная и непонятная система, как и Windows. Но стоит все-таки попробовать разобраться с shell — хотя бы для того, чтобы посмотреть, как правильно администрируются информационные системы.
6 comments:
Вы только забыли упомянуть, что сам язык Shell - крайне архаичный, запутанный, имеющий несколько несовместимых версий и тормозной. А система конвейеров годится только для передачи простой текстовой информации.
Юрий, и да и нет.
Во-первых, ваши эпитеты можно применить к большинству современных языков, и если они будут быстрыми, как С или С++, то окажутся архаичными, запутанными и с несколькими несовместимыми версиями, а если современыми, как Ruby и Python, то тормозными и, порой, не менее запутанными, и опять же, с несколькими несовместимыми версиями.
Во-вторых, для каждой задачи должен быть подходящий инструмент. В данном случае Shell рассматривался как правильный инструмент взаимодействия с ОС, а не как, например, язык для инструмент бизнес- или веб-приложений. И, конечно, он далек от идеала. Конечно, ZetaLisp в этом отношении был лучше... ;)
Если говорить о текстовых языках взаимодействия с ОС, то DCL (в командном режиме, а не в командных файлах) так никто и не превзошел. Shell с его запутанными и нелогичными командами выглядит слабенько.
И вы очень сильно сужаете применение Шелла. Он задумывался не просто как средство общения с системой, а как универсальный клей, соединяющий разрозненные программы, именно с целью создания больших приложений. Говоря по-современному, в качестве скриптового языка.
Но реально в этом он тоже слаб, поскольку может соединять только программы, обменивающиеся текстом, что бесполезно для всего, запускаемого под X Window.
Возможно, для своего времени Шелл и был прорывом (например, на фоне JCL), но с тех пор прошло уже тридцать лет практически без всякого прогресса.
P.S. Автодополнение, которым так гордятся нынешние линуксоиды, придумали в 1969 году, еще в системе TOPS-20.
Для того, чтоб чем-то гордиться, не нужно, чтобы оно было придуманно вчера. Важно, что это действительно работает и решает проблему.
А что до Шелла как скриптового языка, то в этой статье я такой вариант даже не рассматривал, поскольку, как и вы, согласен, что для этих целей это не лучший вариант. Мое мнение, что Guile Scheme, который в свое время предлагался GNU как стандартное решение для этой задачи -- лучше всего (но у меня предубеждение в пользу Лиспа)
Дети-линуксоиды очень часто считают, что это все в Линуксе придумали.
Насчет Scheme согласен - Лисп лучше и богаче.
Правда, рекомендовать что один, что другой в качестве скриптового языка для широких масс я бы поостерегся.
ну так, он же и не прижился...
Post a Comment