Я часто превозносил философию Unix, и, как следует из названия, я не собираюсь останавливаться. До того, как я изучил информатику, я думал, что все компьютеры непостижимо загадочны. Но когда я понял Unix через несовершенную среду Linux, это стало для меня интуитивно понятным. На протяжении всей своей эволюции Unix в своей основе сохраняет то очарование, о котором я говорил ранее.
Если коснуться одной такой черты, которая имеет отношение к тому, что я хочу сказать, мне нравится, что простейшие инструменты Unix также являются наиболее универсальными. Это связано с тем, что его создатели считали, что несколько инструментов по умолчанию должны позволять пользователям делать все, что только можно вообразить. С этой целью «родители мозга» Unix также обеспечили легкое взаимодействие через общий интерфейс текстовых данных. Все эти варианты дизайна сознательно облегчили свободу пользователя.
Но здесь есть важная оговорка: свобода имеет разумные подразумеваемые пределы. Философии, главной добродетелью которых является освобождение приверженцев, никогда не смогут позволить себе избавиться от всех ограничений из-за того простого факта, что философия без доктрин скромна. Философия, как существующая, определяет то, что она есть, и таким образом неявно очерчивает то, чем она не является.
Это то, что я называю «парадоксом даосизма». Не вдаваясь в эзотерику, даосская философия утверждает, что все происходит совершенно без усилий. Существование такое, каким оно должно быть. Фактически, его природа настолько всеобъемлюща, что дать определение невозможно. Итак, как даосизм выражает это, если выражение даосизма невозможно?
Так к чему я к этому вернусь?
Unix сознательно позволяет вам идти любым путем, которым вы хотите, да, но в некоторых случаях вы можете не должен хотеть идти. Изучая инновации в технологическом секторе, я вижу признаки того, что старые традиции исчезают. Я не из тех, кто освящает традицию ради традиции, но я вижу заслугу в сохранении традиционного подхода к вычислительным задачам, поощряющего проницательность.
Чтобы проиллюстрировать, что я имею в виду, это несколько способов, которыми мы отклоняемся от пути Unix, и мой взгляд на то, почему мы должны вернуться на этот путь.
Содержание статьи
Используйте «кошек» ответственно
Команда «cat» — это примерный пример изящно простых инструментов Unix. Он делает одно — выгружает содержимое всех переданных аргументов, и делает это блестяще. Однако, как ни полезен любой инструмент, им можно злоупотреблять. Немногие команды могут быть настолько вопиюще неправильны из-за чрезмерного использования, как "кот". У этого даже есть название: бесполезное использование кошки (UUOC).
Идея состоит в том, что вы не должны использовать «cat» каждый раз, когда вам нужно работать с содержимым файла, потому что многие инструменты могут сами читать содержимое файла. Наиболее распространенный пример этой ошибки — запуск «cat» в файле, а затем передача его по конвейеру в «grep» для поиска по шаблону. В этом нет необходимости, потому что «grep» уже может читать файлы: просто передайте файл в качестве дополнительного аргумента после регулярного выражения. Поэтому вам следует предпочесть вторую из этих двух команд первой.
$ cat файл | grep регулярное выражение
$ grep файл регулярного выражения
Почему это важно? Меньшее количество команд означает меньше циклов процессора. Правда, обычно это не имеет значения, но если вы попадете в эту схему, вы заплатите за нее, когда это произойдет.
Что еще более важно, нарушение UUOC закрепляет дурную привычку не до конца понимать инструмент, прежде чем комбинировать его с другим. Если вы не использовали «grep» для чтения файла, это означает, что вы недостаточно изучили «grep».
Это не академическое упражнение. В учебном пособии по широко распространенному веб-сервису, который часто включает конфигурацию Linux, автор инструктирует пользователей именно таким образом передавать «cat» в «grep». Для тех читателей, которые не знают лучше, они усваивают вредную привычку, не осознавая ее как таковую.
Проверьте цель перед тем, как приступить к убийству
Не всегда все идет по плану. Чем больше дела идут, тем больше они идут наперекосяк. Достаточно сказать, что в компьютерах много чего происходит.
Сигналы уничтожения Unix по-прежнему являются золотым стандартом для остановки зависших программ. Речь идет не о главной команде, которая передает эти сигналы, «kill», а об ужасающе удобном «pkill». В лучших практиках Unix ищут идентификатор процесса программы (PID), а затем передают его в «kill». Например, если ваш браузер завис, укажите свои процессы с помощью следующей команды и найдите запись своего браузера.
$ ps aux
Допустим, PID вашего браузера равен 5000. Затем мы передаем его функции «kill», и он выполняет удар.
$ kill 5000
Самый популярный способ сделать это сейчас — просто присвоить программе имя «pkill» и позволить ей выяснить, кого отключить.
$ pkill program
Но что произойдет, если вы неправильно введете имя программы? Что, если его вызовет другая запущенная программа (или программа, содержащая это имя)? Если указать его только по имени, то легко убить неправильный процесс. Вы бы не сказали почтальону из США доставить посылку «Джону Смиту», потому что кто знает, где она окажется? Вы не должны использовать pkill таким образом по той же причине.
Когда все сделано и готово
Еще одна загадочная практика, которую я увидел при просмотре того же руководства по веб-сервисам, заключалась в редактировании файлов конфигурации с помощью sed. Я ничего не имею против sed. Напротив, это мой любимый инструмент для преобразования текста. Однако при настройке программного обеспечения на это не полагаться.
Я не собираюсь утверждать со стопроцентной уверенностью, что использование sed для настройки конфигураций не относится к Unix, но это неразумно. При редактировании файлов конфигурации обычно безопаснее делать это вручную с помощью текстового редактора. Для этого есть несколько причин.
Во-первых, вам будет проще просматривать свои изменения, поскольку вы находитесь в файле, измененные строки в представлении. Когда выполняется "sed", выходных данных нет, поэтому вы не можете сразу проверить, что изменилось.
Во-вторых, разработчики время от времени изменяют формат файлов конфигурации или изменяют параметры, включенные и закомментированные по умолчанию, в обновлениях программного обеспечения программы. Когда вы применяете команду «sed» к файлу конфигурации, поскольку она указывает, что нужно найти и чем заменить, вы делаете предположения о содержимом этого файла.
Я боюсь, что умелое использование «sed» становится утерянным искусством, потому что не всегда кажется, что авторы учебников полностью осознают возможные крайние случаи для своих команд. Например, я вижу множество материалов, использующих флаг «g», когда это не обязательно уместно или хорошая идея.
Для прохождения самого ухабистого из ускоренных курсов «sed», «sed» требует строки сценария и некоторого текста для работы. «Sed» может многое сделать, но обычно используется поиск и замена, что выполняется с помощью сценария в этом формате.
sed 's / find_exp / replace_lit /'
Это находит каждую строку с регулярным выражением find_exp и заменяет первое вхождение этого выражения в строке с буквальным replace_lit .
Добавление «g» после завершающей косой черты указывает «sed» заменить все вхождения find_exp на replace_lit в любой строке, содержащей find_exp .
]
Команды редактирования файла конфигурации 'sed', которые я видел, используют флаг "g", несмотря на то, что нельзя изменять все экземпляры в строке и не следует предполагать, что в каждой строке есть только один экземпляр. . Когда я впервые выучил «sed», я научился добавлять «g» как «именно так, как это делается», но, хотя теперь я знаю лучше, я не единственный, кто усвоил это ошибочное предположение.
Сохранение пути Unix от пути Додо
Если я выполнил свою работу, я надеюсь, что я убедил вас, что, по крайней мере, эти методы не являются продуктом скучных обычаев, а преднамеренно сосредоточены на оптимальные результаты. Каким бы абстрактным он ни казался временами, Unix-метод — лучший из известных мне способов повышения уровня владения такими системами, повышения эффективности программирования или практического применения каких-либо принципов информатики
.
