Как стать автором
Обновить

Комментарии 73

Выглядит чересчур многобуквенно. Нет ли у этой утилиты коротких ключей, желательно, как и у ls, односимвольных?
Почти для всего есть.
exa --help
Usage:
exa [options] [files...]

-?, --help show list of command-line options
-v, --version show version of exa

DISPLAY OPTIONS
-1, --oneline display one entry per line
-l, --long display extended file metadata as a table
-G, --grid display entries as a grid (default)
-x, --across sort the grid across, rather than downwards
-R, --recurse recurse into directories
-T, --tree recurse into directories as a tree
-F, --classify display type indicator by file names
--colo[u]r=WHEN when to use terminal colours (always, auto, never)
--colo[u]r-scale highlight levels of file sizes distinctly

FILTERING AND SORTING OPTIONS
-a, --all show hidden and 'dot' files
-d, --list-dirs list directories like regular files
-L, --level DEPTH limit the depth of recursion
-r, --reverse reverse the sort order
-s, --sort SORT_FIELD which field to sort by
--group-directories-first list directories before other files
-D, --only-dirs list only directories
-I, --ignore-glob GLOBS glob patterns (pipe-separated) of files to ignore
--git-ignore Ignore files mentioned in '.gitignore'
Valid sort fields: name, Name, extension, Extension, size, type,
modified, accessed, created, inode, and none.
date, time, old, and new all refer to modified.

LONG VIEW OPTIONS
-b, --binary list file sizes with binary prefixes
-B, --bytes list file sizes in bytes, without any prefixes
-g, --group list each file's group
-h, --header add a header row to each column
-H, --links list each file's number of hard links
-i, --inode list each file's inode number
-m, --modified use the modified timestamp field
-S, --blocks show number of file system blocks
-t, --time FIELD which timestamp field to list (modified, accessed, created)
-u, --accessed use the accessed timestamp field
-U, --created use the created timestamp field
--time-style how to format timestamps (default, iso, long-iso, full-iso)
--git list each file's Git status, if tracked or ignored
-@, --extended list each file's extended attributes and sizes
Я просто создал alias c `ls` на `exa` и всякие OhMyZsh и OhMyFish по
`ll` печатают через exa и запоминать ничего нового не надо.
Мда, Хабр превращается в помойку, нет никакого желания делиться наработками.

и другой админ, пришедший на твое место после тебя, будет плеваться от нестандартного поведения ls

Если другой админ будет работать под старой учёткой, то пусть плюётся.
И вообще, зачем тратить на это время, если есть exa?

Зачем тратить на это время, если есть stat?

В статье есть несколько удобных примеров для пользователей git (но есть же gitk и IDE), но в остальном — ls просто не забирает хлеб у штатных stat/getfattr/find, поэтому ставить еще одну программу, пока она не вошла в дистрибутив по умолчанию — нет особого смысла. Если мне нужна удобная и красивая навигация, разве не лучше поставить mc?

Было бы интересны примеры, как exa может заменить stat/getfattr, а примеры из статьи мне показались недостаточно убедительными, например этот:
Exa не просто знает, что такое симлинк, она может по симлинку найти и отобразить фактическое местоположение файла.


Так и ls тоже может:
$ ls -lF /etc/localtime /etc/resolv.conf
lrwxrwxrwx 1 root root 31 Feb 24 03:01 /etc/localtime -> /usr/share/zoneinfo/Europe/Kiev
lrwxrwxrwx 1 root root 39 Aug  5  2019 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Зачем тратить на это время

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

Я прочитал исходную статью на английском.
Оригинальный автор — девушка в Индии: «She is an RHCSA and is working her way to RHCA.»
Будьте снисходительны.
Ну, и в оригинале нет такой вычурности, какая появилась при переводе. Про симлинки в оригинале было просто: «Exa understands symlinks and also points out the actual file.»
Девушек на галерах даже пираты не использовали (на веслах, по крайней мере).
А тут без зазрения… Вот гады.
разве не лучше поставить mc

В mc вымораживает постоянные мусорные символы «OA» и прочие символы вместо ожидаемый функций клавиш когда жмешь Home, End или клавиши курсора, и эти символы потом ещё стирать нужно… кто-нибудь знает как с этим бороться?

export TERM=xterm (или linux) и всё работает в самом xterm или из putty, в последнем нужно выбрать в настройках Terminal/Keyboard/Function Keys ESC[n~.

Самая боль это изредка (настолько редко, что не успеваешь заучить комбинации как бэкспейс например нажать) к hp-ux подключаться. Привычные толком не работает, обычные команды ругаются на ключи и.т.д. Боль.
Ещё боль — это подключаться на сервера, где стоят урезанные линуксы, типа box. В них привычные команды, типа grep или find, имеют урезанный функционал, для «сокращения размера дистрибутива». И для выполнения привычных линуксоидных операций приходится извращаться.

скорее всего шпукс не знает ваш новомодный TERM, нужно выбрать что-то типа того же xterm и все условно заработает

Возможно, дело в настройках терминала или локали? Уже давно с таким не сталкивался.
Если у вас не UTF-8, то попробуйте поставить en_US.UTF-8 (и выбрать utf8 в настройках ssh клиента).
И в отличие от coreutils, тащить exa в продакшен в приличных компаниях может не получиться, максимум на рабочие станции полутора эстетов.
на языке Rust, который хорошо зарекомендовал себя из-за высокой скорости работы, повышенной безопасности и качественной реализации параллелизма

Охренеть насколько важные параметры при разработке утилиты, рисующей в терминале список файлов.


Дерево прекрасно рисуется командой tree, симлинки вполне себе показывает и ls на дебиане почти что десятилетней давности. Разве что с гитом затык и выхлоп git status не настолько же читабелен. О чём кино-то?

Для ls это может быть и не так важно, но вот если взять какой-нибудь grep в рекурсивном режиме — он будет делать это в один поток.
К сожалению, на с/с++ так и не осилили добавить в grep многопоточность, хотя есть варианты с костылями.


А на расте многопоточность делается легко и безопасно, собственно поэтому и пишут


на языке Rust, который хорошо зарекомендовал себя из-за высокой скорости работы, повышенной безопасности и качественной реализации параллелизма
но вот если взять какой-нибудь grep в рекурсивном режиме — он будет делать это в один поток.

А что умеет делать еxa из того, что умеет делать grep?
Вероятно, речь шла об утилите ripgrep, тоже написанной на Rust, которая заметно обгоняет по производительности grep.
Сделать непереносимыми скрипты с его использованием. :)
на языке Rust, который хорошо зарекомендовал себя из-за высокой скорости работы, повышенной безопасности и качественной реализации параллелизма
Охренеть насколько важные параметры при разработке утилиты, рисующей в терминале список файлов.

Думаю, это примерно как пишут "ИГИЛ". Если это не институт гидродинамики им. М.А.Лавреньтева, то правильно должно быть "ИГИЛ*" с пометкой "запрещённая организация".
Так и тут, к любому упоминанию RUST приписывается список всех его известных свистелок (иначе никто же не оценит!)

Так и не понял — всё-таки почему нужно использовать exa вместо ls? Какие доводы то? Цветное и ls показывает. Не увидел нового функционала.
на языке Rust, который хорошо зарекомендовал себя из-за высокой скорости работы,

При этом, exa гораздо медленнее работает, особенно с сортировками.
Дак в чем прикол то?
Или это первое апреля?

Ну как, если кто помнит все ключи ls наизусть, но гибкости всё равно не хватает — тогда можно поставить exe.

Но вывод ls по умолчанию [по мнению автора] не совсем приятен для глаз, поэтому приходится выкручиваться.

Вывод по умолчанию у обоих утилит абсолютно одинаков, лишь цветовые схемы чуток различаются
При этом утилита быстрая, компактная и поставляется с одним единственным бинарником

ну давайте проверим, какая она компактная


$ du -h $(which exa) $(which ls)
1.4M    /usr/bin/exa
140K    /usr/bin/ls

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

хотя чего еще ждать от проекта на расте

А ведь так хорошо комментарий без этой приписки читался… У вас есть какие-то сведения о среднем низком качестве кода в проектах на расте?

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

Абсолютно согласен. Даже, если по аналогии сравнивать top и htop (они так же параллельны как ls и exa)


$ du -h $(which top) $(which htop)
108K    /usr/bin/top
184K    /usr/bin/htop

то htop — отличная альтернатива. Функционала больше и размер соответствующий. Но у exa размер x10, а польза +20%.


Автору спасибо, но нет.


P.S. В инете везде пишут, что раст заменит С в будущем как системный язык, но если он генерит в 10 раз жирнее код, то пойдука я мимо.

Он не код жирнее генерит, он просто линкуется статически.

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

статический или динамический жир… какая разница? не нативные либы в системе тоже можно назвать жиром. Плюс, ls работает в разы быстрее. Это разве не говорит о качестве?

Разница в том, что с ростом объёма кода объём "жира" не увеличивается.

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

Тут такое дело...


$ ldd `which ls`
        linux-vdso.so.1 (0x00007fff689b3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f056e780000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f056e978000)

у ls жира нет ВООБЩЕ, она использует только libc. Сколько и какого жира rust положил в мегабайтный экзешник? Он точно там нужен?

Зависимости
[dependencies]
ansi_term = "0.12"
datetime = "0.5"
glob = "0.3"
lazy_static = "1.3"
libc = "0.2"
locale = "0.2"
log = "0.4"
natord = "1.0"
num_cpus = "1.10"
number_prefix = "0.4"
scoped_threadpool = "0.1"
term_grid = "0.1"
term_size = "0.3"
unicode-width = "0.1"
users = "0.11"
zoneinfo_compiled = "0.5"

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

В Rust своя собственная стандартная библиотека линкуется статически.

У ls весь жир в динамических библиотеках и в POSIX совместимой ОС.


Во FreeBSD есть директория /rescue, где на всякий случай собраны типичные утилиты со статической линковкой:


ls -l /rescue/ls

-r-xr-xr-x 146 root wheel 13587336 28 марта 15:02 ls*


И обычная, с динамической линковкой:


ls -l /bin/ls

-r-xr-xr-x 1 root wheel 33560 28 марта 15:02 /bin/ls*


Пока у Rust не появится стабильное ABI, о маленьких бинарниках можно забыть, как и у Go.


P/S Про Фряху наврал, там в /rescue один большой бинарник со всеми утилитами типа busybox. Но масштаб можно оценить.

Компактнее в 1/10 раза :-D По первоапрельски прям.
Так, статья и есть первоапрельская шутка. Я на словах
Установка exa
Всё предельно просто:
$ dnf install exa
чуть чаем не подавился.
Автор статьи превентивно считает, что у всех стоит «шляпный» дистрибутив.

EDIT: Претензия снимается, посмотрел оригинал статьи, там написано «Sudeshna Sur (Red Hat, Correspondent)». Вопросы отпадают.
Автор статьи превентивно считает, что у всех стоит «шляпный» дистрибутив.
Ну вот тут, кстати, не соглашусь вообще: почему-то убунтуводам/дебианщикам писать apt install в каждой первой статье можно, а федорщикам/редхатовцам аналогичный dnf install — нельзя…
Я после прочтения статьи сделал в голове очевидную замену "dnf install" в "apt install", но это не изменило того печального факта, что ни exa, ни упомянутого в каментах LSDeluxe не найдено в репозитории LinuxMint 20 (хотя на машине с "Debian Buster" пакет exa я позже нашел).
Это дискриминация дистрибутивами по RUST-овому принципу!
Расскажу вам историю про пакеты.
Пишу программу, использую Fedora (мне она больше нравится). После добавления некоторых новых фич, она стала медленно работать, я поэтому я решиль отпрофилировать её с помощью perf и FlameGraphs. Я смог их установить одной командой: dnf install perf flamegraph flamegraph-stackcollapse-perf. Всё заработало с первой попытки.
Поскольку основной средой для запуска являются облачные виртуалки с Ubuntu, я решил, что надо бы отпрофилировать эту программу в одной из этих виртуалок. Каково же было моё удивление, что пакета perf нет вообще (надо ставить linux-tools-что-то там), после установки нужного пакета команда perf появляется, но не работает (потому что у неё нет в зависимостях нужных хедеров ядра), а FlameGraphs вообще отсутствуют как пакет, только клонировать с GitHub'а. Хорошо, что на момент запуска у меня уже были все нужные perl-пакеты, а то бы я вообще с ума сошёл.

Кстати, а ripgrep или хотя бы сам rust есть в вашем дистрибутиве? Правда интересно.
Ну, вряд ли мой опыт будет полезен. LInuxMint 20.1 это Ubuntu Focal (20.04) с доп. репозиторием фирменной оболочки Cinnamon поверх.
Да, ripgrep и rustc есть, и также perf-tools-unstable находится, но нет flamegraph.
В Debian такая же ситуация, только версии постарше.

Возможно всё есть в debian-unstable, но я склоняюсь к парадигме всегда использовать библиотеки из репозитория и только в крайнем случае собирать самому.
Для особых случаев есть возможность использовать PPA-репозитории.

P.S.: После обновления LM 20 -> LM 20.1, пакет exa появился, но все еще не хватает lsd.
Там ещё часть «ненужной» безопасности выпилена (по крайней мере, в одной из версий примерно десятилетней давности), очень был удивлён в своё время. Не помню что именно, но что-то именно связанное с установкой пакетов и заметное уже в графическом диалоге настройки источников, кажется
но все еще не хватает lsd
даже шутить не стану

пожалуй добавлю, что в некоторых сборках (в альпине, к примеру) busybox весит в 2 раза меньше, чем этот exa
С другой стороны, ls из бизибокса не умеет прикольно так подсве…
стоп, а ведь он даже это умеет

Есть ещё замечательная lsd. Тоже написана на Rust. Сравнительный анализ c exa я не проводил, но лично мне хватает возможностей, +можно кастомизировать через конфиг.
image
Раскраска в духе названия :)
А что у тебя за оболочка?
Скрин с оф. сайта утилиты. У меня связка zsh+zsh-syntax-highlighting+zsh-autosuggestions+zsh-completions. Для lsd требуются шрифты с глифами (nerd font, font awesome в помощь). А вообще конкретно lsd пофигу, где работать :)
P.S.: Свой скрин могу позже скинуть, сейчас не за компом.
Тут не в оболочке дело, а в powerline
Пока она не будет по-умолчанию установлена в большинстве дистрибутивов — смысла нет. Переучиваться только затем, чтобы сев на другую машину вводить привычную команду, материться и всё равно набирать ls? Спасибо, увольте.
Думаю не хватает одного полезного тега с сегодняшней датой. Тогда бы я похвалил за изящность троллинга.
НЛО прилетело и опубликовало эту надпись здесь

Да все цвета в терминале – издевательство, хотя бы потому что не все ставят черный цвет на бэкграунд. У меня, например, и темно-красный, и синий, и серый, и черный для разных серверов/задач. В iTerm есть настройка "минимальный контраст", только это и спасает.

alias ll='ls -alF' — по дефолту в убунте стоит.

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

в новых дистрах и так боль была отказаться от ifconfig, хотя ip и ss мне со временем понравились.
разные цвета для разных форматов файлов в выводе ls легко и непринужденно кастомизируются (переменная LS_COLOR), + подчеркивания, жирность, мигания, и может еще чтото забыл. где бенчмарки что exa быстрее?

Это в Федорином горе такой пакетный руководитель. То же, что и apt в debian.

Картинка-c-xkcd-про-стандарты-переделанная-в-картинку-про-ls.jpeg

Установка exa


Всё предельно просто:


$ dnf install exa
Command 'dnf' not found, did you mean:
 command 'df' from deb coreutils
Try: sudo apt install <deb name>

$ sudo apt install exa
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package exa
Пропал дух авантюризма… А как же «в линуксе всё можно собрать из исходников»?

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

Как говорится, «Я Linux 2.4/2.6 собирал, QT3/4 собирал и имел уважаение!».
В планах двигаться дальше: попробовать пособирать KDE, Firefox и Chromium…
А для адептов Gentoo мои подвиги — детский лепет.
всё норм:
~ emerge exa
* Last emerge --sync was Вс 4 апр 2021 09:35:01.
Calculating dependencies ... done!
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-apps/exa-0.9.0-r1::gentoo
>>> Installing (1 of 1) sys-apps/exa-0.9.0-r1::gentoo
>>> Recording sys-apps/exa in "world" favorites file...
>>> Jobs: 1 of 1 complete Load avg: 3.52, 2.42, 1.91
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

Со скриншотами просто беда! Не замыленные версии есть?

А зачем под каждым скрином имя, которое совпадаем с именем именем автора, да еще и лицензия, да еще и с версией. При том, что лицензия — CC?

Как будто бы кто-то просто переписал ls на rust и добавил 1.5 плюхи, а цель реклама очередного чего-то там на rust'е

Зарегистрируйтесь на Хабре, чтобы оставить комментарий