Pull to refresh

Comments 53

git init ~/; git status

Я там поправочку вносил, чтобы мусора не оставалось:
git init ~/ ; git status; rm -rf .git
Это да, я бездумно добавил из исходного примера с просмотром текущей директории.
А вот так попроще будет:
git init ~/ ; cd ~ ; git status; rm -rf .git; cd -

Кстати, будет досадно, если в исследуемом каталоге .git уже был. :)
Можно завернуть в subshell, чтобы cd обратно не делать.
Кстати, да, я вечно про него забываю.
Всё хорошо с Git, кроме одного косяка…
"\320\224\320\276\320\272\321\203\320\274\320\265\320\275\321\202\321\213/"
"\320\227\320\260\320\263\321\200\321\203\320\267\320\272\320\270/"
"\320\230\320\267\320\276\320\261\321\200\320\260\320\266\320\265\320\275\320\270\321\217/"
"\320\234\321\203\320\267\321\213\320\272\320\260/"
"\320\240\320\260\320\261\320\276\321\207\320\270\320\271 \321\201\321\202\320\276\320\273/"

Это собственно каталоги с русскими именами. Шаблоны, Рабочий стол, вот это вот всё. ;-)
git config —global core.quotepath off

Пользуйтесь на здоровье :)
grep -l '.*' ~/* ~/.* | grep -L '.*' ~/* ~/.* 2>/dev/null

Всё же
grep -l '.*' ~/* ~/.* 2>/dev/null || grep -L '.*' ~/* ~/.* 2>/dev/null

Кстати, я так и не понял в чем прелесть. Одно время использовал alias ls=exa, но потом перестал, т.к. разницы с ls --color -F почти и нет.


Какие-то преимущества у exa наверное и есть, но для человека, проработавшего в bash десятилетями, они настолько незначительны, что игра не стоит свеч, по-моему.


А если относительно темы статьи, то это похоже на читерство. И exa вряд ли распространенный инструмент.

В больших каталогах это будет не быстро.

О да, больше glob'а. Это так неожиданно. /сарказм

вот-вот, странно читать «с помощью XXX», а всю работу выполняет шелл, развернувший *.
упомянуть об этом способе нужно, конечно, но не преподносить его как 20 разных способов же.

В некоторых способах можно и без него обойтись, даже в моем варианте с rm. Добавить флаг -r и добавить один символ в grep. Для меня это очевидная альтернатива, но я не написал этот вариант именно в таком исполнении, потому что он может выполняться бесконечно долго.

В некоторых способах можно и без него обойтись

там, где можно обойтись (и обошлись) — там это отдельный способ. где используется * — один.
не написали же миллион способов с find, хотя все способы с * можно переписать на find.

Это настолько очевидно, что было в первой статье.

Не знаю, как так получилось, но в первой статье нет моего второго комментария (забыл нажать кнопку "Опубликовать?").


Просто на всякий случай напоминаю условия задачи:


Выведите список файлов в домашней директории максимально возможным количеством способов, без использования ls или его алиасов(1 способ — 1 балл)

Варианты решения:


  • mc $HOME
  • nautilus $HOME
  • gopen $HOME — можно даже так
  • ...
  • ну не буду же я перечислять все файловые менеджеры

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

Ну все, что я могу добавить для случая с похереными базовыми утилитами по ssh: chromium-browser "file://$HOME"


Вообще, я не зря привел условие задачи в своем комментарии.

А я как-то ковырялся по телнету в роутере, где ls попросту отсутствовал в бизибоксе.

Да, и такое бывает. А еще бывает когда есть ls, но нет mv/cat/cp/etc… Нужна еще серия статей для поиска альтернатив другим утилитам! :)

Ну вроде того, но хотелось бы больше извращений как в этой статье :)
Но статья отличная, спасибо!

Ох! Какая знатная замена трейсруту! Спасибо за ссылку.
Знатная замена трейсруту — mtr (my traceroute)
А тот наколенный скрипт не показывает хопы, которые не отвечают.
Какая годнота! И даже в репах манджары.
chown -v -R root:root ./

Главное, от рута по рассеянности не запустить. :)
И мусора в выхлопе много.
И в директории лезет, по понятным причинам.
Ну так -R убрать, и не полезет. А зачем там -v, непонятно — chown и так руга… А-а! автор надеялся, что будут запускать таки от рута! )))
теперь нужны бенчмарки для всех команд, какая из них эффективнее справляется с задачей) (быстрее работает с большим количеством папок)
теперь нужны бенчмарки

Прошелся по примерам в первой статье.
Тестовая дира — плоский каталог, около 15 тыщ файлов.
Делать лень, взял готовый.
$ ll | wc -l
14881

Выхлоп везде поскипан, естессно.

Бенчим
1)
time for i in ./*  ./.* ; do echo $i ; done
...
real  0m0,263s
user  0m0,189s
sys 0m0,051s

time echo ./* ./.*
...
real  0m0,111s
user  0m0,070s
sys 0m0,008s


2)
(пришлось устанавливать, искаропка подвела)
time tree -aiL 1
...
real  0m0,226s
user  0m0,127s
sys 0m0,064s


3)
time find . -maxdepth 1 -mindepth 1
...
real  0m0,117s
user  0m0,039s
sys 0m0,034s


4)
time du -ad 1 .
...
real  0m0,164s
user  0m0,027s
sys 0m0,076s


5)
time tar -cvf /dev/null --no-recursion ./* ./.* 2>null
...
real  0m0,265s
user  0m0,121s
sys 0m0,111s


6)
time perl -e 'use feature "say"; opendir my $dh, "." or die "Could not open . for reading: $!\n"; while (my $thing = readdir $dh) { say $thing; };'
...
real  0m0,112s
user  0m0,038s
sys 0m0,029s


7)
time echo -e "import os\nfor i in os.listdir('.'): print(i)" | python
...
real  0m0,120s
user  0m0,032s
sys 0m0,039s


Мой вариант:
time rsync --list-only ./
...
real  0m0,210s
user  0m0,094s
sys 0m0,091s


Сама ls:
time ls
...
real  0m0,223s
user  0m0,103s
sys 0m0,043s

Всего чего угодно ожидал но не того что питон и перл порвут ls…
На прогретом кэше — почему нет? Чтением каталога все равно сишные программы занимаются, интерпретаторы чисто обертка. Баш, кстати, тоже интерпретатор.

А ls, что ls… оно по умолчанию, еще и сортирует. А без сортировки, вот:
time ls -f
...
real	0m0,114s
user	0m0,030s
sys	0m0,026s

И кто знает, что там набенчится, если перл заставить сорт… Черт! Вспомнился чудный перл с баша:
* Daemon потыкал палочкой в wd
яя
а чиво станет с перлом, если в хеш загнать 2 гига данных и заставить перл его сортировать?
будет сортировать
неожиданно

Мне кажется или в вариантах с глобами правильнее делать time bash -c '...', чтобы время разворачивания глобов тоже учитывалось?

Нет, разброс от запуска к запуску больше, чем разница между вариантами с bash -c и без.
Правильнее делать многократные измерения с усреднением, но мне лень. :)

У меня так (time из zsh):


Заголовок спойлера

1) Запускал через bash, потому что zsh отказывается замерять время работы echo напрямую


bash -c 'for i in ./*  ./.* ; do echo $i ; done'  0.01s user 0.00s system 97% cpu 0.011 total

bash -c 'echo ./* ./.*'  0.01s user 0.00s system 96% cpu 0.009 total

2) Тоже пришлось устанавливать


tree -aiL 1  0.01s user 0.00s system 96% cpu 0.010 total

3)


find . -maxdepth 1 -mindepth 1  0.01s user 0.00s system 95% cpu 0.008 total

4) Ожидаемо сильно страдает от большого числа вложенных директорий


du -ad 1 .  1.46s user 17.90s system 6% cpu 4:38.79 total

5)


tar -cvf /dev/null --no-recursion ./* ./.* 2> null  0.12s user 0.00s system 90% cpu 0.134 total

6)


perl -e   0.01s user 0.00s system 23% cpu 0.024 total

7)


python  0.03s user 0.01s system 90% cpu 0.034 total

rsync


rsync --list-only ./  0.01s user 0.01s system 82% cpu 0.016 total

ls


ls --color=auto  0.01s user 0.01s system 5% cpu 0.259 total

ls --color=no  0.01s user 0.00s system 95% cpu 0.009 total

Таки все варианты с глоббингом это один вариант с глоббингом, echo ./* ./.*. Таки список файлов в таком варианте даёт шелл, а не что-нибудь.

Таки да — уже в нескольких местах мысль повторили.
Удивительно, что всё еще нет картинки про буханку хлеба и троллейбус.
И действительно, как это ни один мимокрокодил, ничего тут не понявший, не набижал с буханкою наперевес?.. (снедаемый эффектом Даннинга-Крюгера)
А зачем? Это же развлечение чисто Just for fun. Ну, как brainfuck какой-нибудь.
А почему докер не упомянули?
docker run --rm -v `pwd`:/tmp busybox ls /tmp

Потому что Вы используете ls, что было запрещено правилами?

интересно, а много ли людей выполняло эти команды на боевом сервере, а не локально у себя
не говорю конкретно про эту команду, а в целом
Only those users with full accounts are able to leave comments. Log in, please.