Ни для кого не секрет, что Mac OS X базируется на BSD, и, как следствие, получила в наследство полный комплект BSD-шных command line утилит, таких как ls, find, xargs, и многие другие. Они хорошие и правильные, и использовать их вполне можно — однако если вы долго использовали Linux, наверняка вы привыкли к GNU версиям этих утилит, то есть, к примеру, --длинным-аргументам, нормальной опции --help — ну и вообще выработали определенные привычки. К числу таких людей принадлежу и я, и когда мне понадобилось набрать пару десятков команд в Terminal.app, через 10 минут я начал рвать волосы на груди нервничать и читать man, что не способствовало производительности труда.
Несколько позже я подумал — а почему, собственно, я не могу использоваться GNU версии утилит — только потому, что они не поставляются с системой? Нет, это — не UNIX way!

Сообщество LS готовит футболки.

Выяснилось что в моем zte 531 b стоит урезанный linux. Однако полноценному его изучению мешает отсутствие в стандартной поставке командочки ls. Оказывается листинг директории можно получить и без нее:

> echo *
CVS bin dev etc lib linuxrc mnt proc sbin usr var webs
>

А натолкнула меня на это подсказка встроенная в cat

> cat *
You should use echo * to list the files
>

 

grep

Многим любителям шела нравится чудная команда grep.
К сожалению, windows нативно не имеет такой команды, по этому некоторые ставят себе наборы различных консольных утилит в *nix стиле, включая grep.

Мне, как любителю посидеть в консоли Windows очень мешало отсутствие грепа, по этому мои скрипты под Win всегда были не так хороши, как могли бы быть. Но мои скрипты должны работать на любой (ну, или почти на любой) Windows, так как же быть?

Продолжение перевода первой части руководства. Начало тут.

В данном отрывке рассмотрены команды работы с файловой системой и файлами, такие как ls, mkdir, touch, mv, cp, затронуто использование echo и cat. Рассказано про иноды файловой системы.

Командная строка Unix полна сюрпризов. Например, вы знали, что инструмент ls, который чаще всего используется для получения списка файлов в текущем каталоге, в версии OS X распознаёт не менее 38 разных флагов?

Я не знал, так что затвитил этот факт. И получил парочку ответов, один из которых заставил меня задуматься: действительно ли саму Unix нужно винить в этом?

Насколько я знаю, ни Linux, ни OS X не были спроектированы в строгом соответствии с философией Unix. Будет лицемерием основывать критику “Unix” только на этих производных от Unix, которые есть у нас сегодня.

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

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

Сегодня мы хотим рассказать о некоторых последних апдейтах системы Sherlock [это высокопроизводительный кластер Стэнфордского университета — прим. пер.], которые значительно ускоряют листинг файлов в каталогах с большим количеством записей.

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

Листинг многих файлов занимает время

Всё началось с вопроса в техподдержку от пользователя. Он сообщил о проблеме, что выполнение ls занимает несколько минут в каталоге c более 15 000 записей в $SCRATCH [каталог для временных файлов — прим. пер.].

Всем привет!

После вчерашнего поста о замене штатного ls другими штатными (или не очень) утилитами, я просто не мог пройти мимо комментов, особенно учитывая то что пост взлетел на вершины хит-парадов и за сутки его прочитало 18k, с хвостиком человек. Хабровчане подарили миру много новых способов избавиться от ls. Я их все (но это не точно) проверил, некоторые «причесал», что бы они соответствовали условиям задачи, и хочу поделиться с вами. Наслаждайтесь!

Моё хобби — открыть «Философию UNIX» Макилроя на одном мониторе, одновременно читая маны на другом.

Первый из принципов Макилроя часто перефразируют как «Делайте что-то одно, но делайте хорошо». Это сокращение от его слов «Создавайте программы, которые делают одну вещь хорошо. Для новой работы создавайте новые программы, а не усложняйте старые добавлением новых "функций"».

Макилрой приводит пример:

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

Если вы откроете справку для ls, то она начинается с

ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]

То есть однобуквенные флаги для ls включают все строчные буквы, кроме {jvyz}, 14-ти прописных букв, @ и 1. Это 22 + 14 + 2 = 38 только односимвольных вариантов.

Изображение: Opensource.com

Цель автора статьи — показать, что exa может легко заменить стандартную утилиту ls. И более того, в сравнении с ls, exa — более гибкий и мощный инструмент.

Стараясь сэкономить время и силы, мы автоматизируем часто повторяющиеся и сложные операции. Например, для отслеживания изменений содержимого каталогов и информации о файлах в Linux-системах многие по-прежнему используют команду ls. Но вывод ls по умолчанию [по мнению автора] не совсем приятен для глаз, поэтому приходится выкручиваться. При работе с ls возникает ещё ряд неудобств, но в этой статье мы не будем про них говорить. И вообще, зачем тратить на это время, если есть exa?