Зачем сборщики пакетов Debian переименовывают и кладут в странные места бинари

Ещё zsh забыли упомянуть, или что там щас модно. А зачем интересно так усердно работать в CLI? Вот приводили выше поиск и потом греп по найденному. Так это всё делается не выходя из вима. Тот же mc тоже годный инструмент, можно обвесить его скриптами, и будет в сто раз удобнее консоледрочества. Все эти утилиты нужны, чтобы склеивать их в скрипте, а не наяривать руками и потом утомившись искать какой-то необыкновенный комбайн.

В 95% случаев, искать среди скрытых и .gitignore не требуется. На то они и «скрытые» и на то они «ignore». Поэтому, наборот, сильнейшим образом напрягает, что для старых find, grep надо колхозить какие-то дополнительные условия, чтобы они не искали там, где не надо.

Я не знаю, что это за workflow такой, у немодного не-смузихлеба, что ему наборот надо искать среди скрытых и игнорируемых. Сдаётся мне, что как раз в этом случае надо что-то в консерватории править.

mc - буэээ

И это как раз инструмент для неосиляторов Unix философии, максимально далёкий от канонов.

Это инструмент для осиляторов здравого смысла, и этого вполне достаточно.

Я конечно не понимаю кому этот оригинальный fd нужен, но народ ставит его, даже на маке

Ну вот с того же brew статистика:

Installs (30 days)
fdclone 9
fd 26,143

И что, это нормально, что в дебиане название fd застолбили за проектом, у которого в 3000 раз меньше пользователей?

Ну, я в принципе, уже в самом начале понял, что те, кто ставят клоунов, и обливают субстанциями ripgrep/fd - не пользуются CLI, а пользуются mc.

Спасибо всем, кто мои подозрения подтвердил.

Юникс запрещает визуализацию перемещений по дереву каталогов? Там кстати внизу такая же командная строка. Плюс чуть более продвинутый интерфейс для выполнения тех же самых команд и скриптов.

Я не знаю, что это за workflow такой, у немодного не-смузихлеба, что ему наборот надо искать среди скрытых и игнорируемых. Сдаётся мне, что как раз в этом случае надо что-то в консерватории править.

У меня почти в каждом проекте есть папка tmp, в которой я держу всё, не относящееся к делу. Поэтому у меня это название в глобальном игноре. И при этом я в этой папке что-то ищу достаточно часто. Не знаю, зачем мне что-то править.

Ещё пример - я собрал программу в папку output, в которой теперь развесистое дерево. И я хочу его проинспектировать для чего-нибудь. Тоже вполне валидный кейс, периодически бывает надо.

Вот конкретно в папке .git искать, конечно, нужно очень редко. А просто в игнорируемых папках - сплошь и рядом.

mc используют только нубы, которые не осилили командную строку. Это было справедливо 30 лет назад, это справедливо и сегодня. Не зря far и totalcommander это одна из самых популярных программ у вендоадминов, у которых палец к мышке прирос.

Ржачно. Фанаты растокомбайнов в один голос хейтят mc.

ripgrep уже умеет делать, как grep -f? Раньше вроде не умел.

Вроде ровно такой же флаг есть.

GREP(1)	
...

-f FILE, --file=FILE
Obtain patterns from FILE, one per line. If this option is used multiple times or is combined with the -e (--regexp) option, search for all patterns given. The empty file contains zero patterns, and therefore matches nothing. If FILE is - , read patterns from standard input.

RG(1)
...

-f PATTERNFILE, --file=PATTERNFILE

Search for patterns from the given file, with one pattern per line. When this flag is used multiple times or in combination with the -e/--regexp flag, then all patterns provided are searched. Empty pattern lines will match all input lines, and the newline is not counted as part of the pattern.
A line is printed if and only if it matches at least one of the patterns.

When PATTERNFILE is -, then stdin will be read for the patterns.

When -f/--file or -e/--regexp is used, then ripgrep treats all positional arguments as files or directories to search.

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

Но - я не ставлю никаких клоунов, против утилит вообще ничего не имею

которые не осилили командную строку

Рассортируй мне по файлопомойке фоточки с телефона командной строкой, попутно удаляя лишние.

Справедливости ради, тут и mc не особо поможет.

Да вообще без проблем.

xdg-open file1.jpg
mv file1.jpg directory1/
xdg-open file2.jpg
rm file2.jpg

И так далее.

И потратить в 20 раз больше времени чем хомячок, а куда нам спешить.

Хомячкам фотки сортирует сири автоматически, а если ты хочешь вручную - страдай, а что поделать.

Я фоточки сортирую по содержимому. Для этого mc также не подходит, а подходят специальные GUI приложения, такие как digikam.

Есть спецсофт, в котором это нормально делается вручную. И это не эмулятор терминала.

Потому что я просто не могу понять, как человек сможет, например, вернуться к использованию grep, попробовав ripgrep. Вообще никак не могу.

Ну вот я хорошо отношусь к хорошим новым вещам. Мне нравятся Rust, Go, я в гробу видал Xorg (эксклюзивно использую Linux на десктопе с 2008-го, был большим поклонником идей X11). Жду uutils/coreutils вместо GNU Coreutils. Но я не понимаю, как люди могут использовать весь этот цветастый хлам вроде fd, rg и прочих eza. Да, оно несколько быстрее, но ничего почти не умеет. Пробовал fd, и оно годится лишь как гламурная замена parallel, потому что ничего толком не может из того, что может тормозной find. Видимо, у людей разные предпочтения.

Смысл fd не в скорости, а в удобстве работы в CLI. То есть, если работаешь непосредственно в shell, всё делаешь в нём. Потому что набирать постоянно многословные команды find - рука отсохнет. То, что в fd требует нажатия 10 клавиш, выраженное в find потребует нажатия 50-100. Когда именно работаешь в CLI, это удобно.

rg удобнее тем, что я, например, разработчик. И когда я ищу что-то в проекте, мне не нужен весь мусор, который найдётся в скрытых каталогах или в том, что я закинул в gitignore. Мне удобно, что по умолчанию поиск рекурсивный, не ищет там, где я уже сказал стандартным образом (через gitignore), что не надо. Что в нём легко можно искать в файлах по типу (-t py, -t yaml, -t cpp), можно легко добавлять или удалять файлы из поиска по маске (-g '!test_*.py') без горождения сложных пайплайнов из find + grep.

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

Ну и цвет… Цвет тоже важен, позволяет быстрее на экране отделить важное от неважного. Цвет, кстати, и в grep поэтому есть уже давным давно.

сила привычки? Я вот за почти 20 лет использования cli что в линуксе, что на маке, уже на автомате набираю часто используемые команды. fd например так и не прижился, rg в целом зашел лучше как drop-in замена (опять же, пришлось писать конфиг, что бы он не учитывал всякие *ignore).

Когда работал админом в кровавом энтерпрайзе использовать что-то экзотическое было совсем неудобно, привыкаешь к одному, а не сервере тебя ждет какой-нибудь ksh с негнутыми find/grep/sed и т.д.

вообще в чем идея учитывать всякие .gitignore и dot-файлы? я понимаю там .git/, но эти-то чем провинились?

И что, это нормально, что в дебиане название fd застолбили за проектом, у которого в 3000 раз меньше пользователей?

Застолбили за проектом, который в репах больше 20 лет уже.

Я и говорю - классический киберсквоттинг.

Для этого mc также не подходит

Там просто чуть выше был еще пассаж этого же специалиста про тоталкоммандер и фар.

И что ты предлагаешь?

Так у меня тоже давно уже все эти паттерны find в подкорке сидят. И перейти на fd для меня было тяжело. Я до сих пор их комбинирую, пользуюсь то одним, то другим. Но всё чаще fd, потому что он действительно удобнее.

Почему удобно учитывать ignore, я уже написал. Тем более, что при необходимости, это тривиально отключается опцией -u, которую можно повторять несколько раз для отмены всё большего количества ограничений.

Например, если говорить про Python: если искать по всем файлам, то при поиске идентификатора, например, будут находиться ненужные дубликаты совпадений в .pyc файлах.

да я знаю и не сомневаюсь что fd-find гораздо более популярен, как раз и удивился что его хоть кто-то вообще ставит)

И что, это нормально, что в дебиане название fd застолбили за проектом, у которого в 3000 раз меньше пользователей?

а почему бы и нет? не сомневаюсь что там таких куча пакетов, но непонятно с чего бы старый проект должен переименовывать себя, раз кто-то еще решил использовать такое имя? Завтра кто-то напишет еще одну популярную утилиту не для поиска (что бы в alternatives не попало) и тоже назовет ее fd, что делать?

с bat кстати ровно такая же история

https://qa.debian.org/popcon-graph.php?packages=bacula-console-qt%2Cbat&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

з.ы. хотя вот конкретно в данном случае я может и был согласен с переименованием fd в какой-нибудь fdclone или fd-legacy, это явно не то, что может поломать уже работающие, покрытые пылью, скрипты

у меня очень часто на работе иногда скрытых файлов чуть ли не больше, чем остальных. всякие .gitlab* .go* и прочее. очень часто все инклюды для гитлаба тоже делают скрытыми и меня, как того, кто должен починить пайплайны, они интересуют больше чем остальное. из серии поискать где-то еще http_proxy могло запрятаться

и вот получается, что старый греп почти сразу ищет что надо (почти - надо бы все-таки .git в игнор добавить) а для рг нужно искать соотвествующие ключи

И так далее.

Ага. Значит, полностью это выглядит примерно вот так:

$ xdg-open "mtp:/Moya Sranaya Mabila/Internal shared storage/DCIM/Camera/IMG20250622220753.jpg"

Так, вроде нужная фоточка, сохраним:

$ mv "mtp:/Moya Sranaya Mabila/Internal shared storage/DCIM/Camera/IMG20250622220753.jpg" "/run/media/mountpoint/long/path/to/photos/dir1"

mv: cannot stat 'mtp:/Moya Sranaya Mabila/Internal shared storage/DCIM/Camera/IMG20250622220753.jpg': No such file or directory

Давай еще рецепты.

Это не так работает

когда я ищу что-то в проекте, мне не нужен весь мусор, который найдётся в скрытых каталогах или в том, что я закинул в gitignore.

Это полный ахтунг, потому что скрытые каталоги скрыты не от поиска. ~/.config тоже скрытый. Игнор гита тоже не имеет никакого отношения к поиску. Нет, раст это все-таки диагноз.

ну, нам разное нужно искать, мне наоборот чаще проще исключить py/java/cs

а вот это

> fd test/                                                                 
[fd error]: The search pattern 'test/' contains a path-separation character ('/') and will not lead to any search results.

If you want to search for all files inside the 'test/' directory, use a match-all pattern:

  fd . 'test/'

не то что бы непреодолимый, но блокер если привык незадумываясь писать find test/ )

ну, нам разное нужно искать, мне наоборот чаще проще исключить py/java/cs

Так мне тоже часто надо что-то исключать. В rg это тоже одна опция. Например, исключить py: -T py.

не то что бы непреодолимый, но блокер если привык незадумываясь писать find test/ )

Я сразу привык, что в fd можно не указывать начальный каталог, это как раз меньше всего затруднений вызвало у меня. Потому что меня всегда бесило, что всегда надо потратить нажатия на то, чтобы написать . -name, в 99% случаев, когда использушь find.

Например Зачем сборщики пакетов Debian переименовывают и кладут в странные места бинари (комментарий)

Учитывая, что в ОС уже есть система альтернатив как раз для разруливания ровно этой ситуации, не использовать её очень странно.

Я сразу привык, что в fd можно не указывать начальный каталог, это как раз меньше всего затруднений вызвало у меня. Потому что меня всегда бесило, что всегда надо потратить нажатия на то, чтобы написать . -name, в 99% случаев, когда использушь find.

Лови маковода. В GNU find начальный каталог писать не надо.

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

Он предлагает создать для всех лютый геморой на ровном месте, прописав пакеты как конфликтующие по имени, альтернативы, но не взаимозаменяемые, либо ls как вывод списка файлов, либо ls как запуск lisp server, устанавливай, только смотри не перепутай. Преемственность наименований для слабаков, apt install foo случайным образом устанавливает 1 пакет из 50, где исполняемый файл имеет имя foo

Это как ругаться на то что на ЛОРе нельзя всем использовать 1 и тот же ник, даалоой старые условности!

• https://i.ibb.co/dnKGTRT/2025-09-25-20-27-05.png

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

ls как запуск lisp server,

ой! а что, ещё и такое бывает? вот так наберёшь где-нить обычный ls, а он исполнит что-то невообразимое :)

Лови маковода. В GNU find начальный каталог писать не надо.

Нет, ни разу в жизни даже не притрагивался к маку. Просто привык, что надо указывать каталог, и не знаю… С какого-то момента не пересматривал эту аксиому, не знаю, с каких времен она у меня в голове засела.

В любом случае, напрягает то, что надо писать -name, и что нельзя искать просто по подстроке, надо писать глоб, а т.к. большинство шеллов либо развернут его (что нам не нужно), либо ругнутся, если он ни с чем не совпал (тоже не нужно), то это требует экранирования, т.е. тянуться ещё либо к бэкслэшу, либо к кавычкам.

В общем, неэргономично.

А если хочешь find’ом искать по регекспам, то там у него опции для поиска регекспами - просто треш и угар.

ну гнутый find тоже не принимает слеш в -name. gfind: warning: ‘-name’ matches against basenames only, but the given pattern contains a directory separator (‘/’), thus the expression will evaluate to false all the time. Did you mean ‘-wholename’?

а fd всегда требует указать строку для поиска, вот и приходится писать fd . test/

Да это я придумал (надо было уточнить), просто vbr говорит что ls закиберсквотил название за собой, типа захватил и никому не отдаёт!

Но так-то есть аркадная игра chromium, а есть браузер chromium, сейчас они называются chromium и chromium-bsu если забить за приемственность имён считая это захватом имени, то получится хотел браузер, а получил игру или наоборот, что само по себе глупо. Конечно порой именования пакетов несовершенны, например есть модуль для lua (спроецирую на себя) и он называется lua-base64 и таких модулей, разных, делающих одно и тоже много, но не взаимозаменяемых… а называются одинаково 10+ штук разных проектов имеют имя lua-base64 и задача майнтейнера порой всунуть в дистр их несколько, один один как C либа, второй как чистый луа модуль, и ещё пару смешанных, надо разруливать именования и месторасположения, причём ещё и по debian policy чтобы было по правилам, единым для всех и понятным, ломая мозг как это сделать, иногда выходит аляпово, но это с виду, или так или никак. Ну или тупо прописывать пакеты как конфликтующие тупо по имени бинаря, а значит взаимоисключаемые, взаимоудаляемые, но это уже шиза, разрешающая включить в дистрибутив игру с названием linux-image которая снесёт ядро нахрен :D

Технически этот вопрос решается, но… в линуксах с HFS так не принято типа кинуть программы в свои каталоги в аля Program Files и при вызове оболочка запуска будет спрашивать что из двух одинаковых файлов запускать, или задавать оболочке вариант вызова того или иного явно указывая это специальным образом. Это разрешить иметь в системе 100500 программ имеющих одинаковое название, с разруливанием через пути расположения и выбором нужного при запуске без указания пути, но эт такое, прикольная техническая задача в целом, но она решается так же как с gcc тупо добавлением постфикса gcc-xx в случае разных версий, и просто похожего но другого названия в случае одновременной установки разных или взаимозаменяемых программ, и всё.

Да я навалил простыню потому что у меня подгорело от слов vbr

Выдыхаю. Выговорился. :D

А надо было всего лишь поступить как авторы sudo-rs. Причем это соглашение официально принято каким-то их конгрессом сектантским. Потом растишки могут алиасом перекрывать православный sudo, и все будут довольны.

ну, у дебиана же есть alternatives, или как там оно называлось. не идеальное, но простое решение для «застолбления» названий.

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

я сама как-то лоханулась. запускаю curl, а он мне выдаёт какую-то невнятную ругань. не могла понять, в чём проблема, пока не поняла, что это из /usr/local запустился curl, который я когда-то для тестирования собирала с gnutls. а /usr/local стоит в путях поиска перед /usr. так что факапы случаются, но не так часто. иногда лучше писать полное имя, чтобы уже наверняка. особенно если у тебя на машине есть тестовые сборки, которые где-то лежат и могут внезапно поднасрать.

Ну в твоём случае, просто забылось что local/bin по приоритету (по умолчанию) поиска выше чем bin, и это активно используется, например можно кинуть в локал скрипт который задаёт стартовые аргументы для основного бинапрника всем пользователям, но сам бинарь не трогать, ну и так далее. А альтернативы, ну, они работают только с альтернативами, использовать vim вместо nano и так далее, для указания альтернативы по смыслу, а не по названию, алтернативой не разрулишь одинаковое именование двух совершенно никак не связанных программ, не можно конечно, но это будет через жопу, либо да указывай при запуске полный путь, либо, используй механизм приоритетов запуска который в PATH виден, либо просто используй префиксы/постфиксы/иные имена, для новых пакетов которые НУПРОЯМОЧЕНЬХОЦАНАДАИНУЖНА вызывать тем же именем что и ранее существовавшую программу.

Количество кратких имён к сожалению физически ограничено, и естественным образом возникают коллизии. Методы их разрешения порой работают, но они имеют свои границы.

Не всем всё нравится, но это не имеет значения, покуда есть именования, эти проблемы универсально физически невозможно решить для всех разом и чтобы всем понравилось решение. Ой короче, нравится нам или нет, но тут в целом есть ряд проблем, и каждый ряд решается своим подходом разрешения ситуаций, ну или тупо пиши полный путь и не выёживайся, главное при это не быть пользователем nixos, а то будешь писать /nix/store/l5rah62vpsr3ap63xmk197y0s1l6g2zx-curl-gnutls/bin/curl :D

Итого. Хочется вжух и красиво как в сказке, но жизнь боль из взаимоисключающих случаев нужных одновременно.

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

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

приоритет каталогов «забыть» невозможно. забылся тот факт, что когда-то я засунула в /usr/local очень специфическую кастомную сборку для тестов.

а пользователи Nix наверняка знали, на что подписались. если не знали, то ссзб. я лично это считаю лютым извращением и попыткой повторить dll hell, но в более грандиозных масштабах.

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

Ладно, чё бубнеть, я на Debian и у меня всё хорошо, в рамках того что мне нужно. А ребята пусть развлекаются с никсами, как ни крути порой хорошие вещи рождаются изподвыверта, не сразу, через множество итераций переделывания, но всё же.