Если поменять местами /usr/local/* и /usr/* в PATH?

ничего не изменится, у тебя скорее всего директория /usr/local/... вообще пуста

вообще, программы в PATH ищутся в директориях в том порядке, в котором они появляются в PATH

Если вы сами или «кто-то другой» не ставил что-то с «одинаковыми названиями» в разные директории то ничего.

или «кто-то другой»

Доверять нельзя никому, даже себе.

То какие программы при этом перестанут работать?

Поменяй и посмотри. btrfs снапшот сделать три секунды. Если будут проблемы, то откатишься назад.

только те, в которых есть идентичные запускаемые имена в usr/local/bin и usr/bin, но отличные по своему действу (к примеру).
не совсем понял зачем такая замена, но както так.

мой пример: для одной джава-програмки я ее скрипт запуска (поставляемый в deb-пакете) заменил на свой скрипт запуска (запускалась чтоб запускалась на 13 версии джавы вместо дефолтной 8). свой скрипт я разместил по пути находящемся «раньше» в списке путей PATH.
больше изменений никаких.

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

Поменяй и посмотри. btrfs снапшот сделать три секунды. Если будут проблемы, то откатишься назад.

Предлагаю более надежный и более удобный способ, делаем бэкап харда с помощью dd, так сказать что бы точно.

Это неудобный способ, потому что бекапится как занятое, так и свободное пространство. Архивация не поможет, так как свободное - это не значит «заполненное нулями».

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

мой пример

В десктоп файле поменяй путь на свой скрипт.

Редко когда нужно иметь две версии утилиты.

Это неудобный способ

Я знаю, поэтому и предложил его в ответ на вариант со снапшотами. Типа не ищем лёгких путей, а только в гамаке и стоя.

Если вы сами накидали что-то старое и древнее в /usr/local/,
то при приоритетах в PATH это старое и древнее будет выполняться всегда, даже если в /usr/ есть вариант свежее.

Иногда это приводит к тому, что начинаешь удивляться, почему оно не обновилось... Ну а вот почему, потому что вы сами себе закладываете грабли на будущее в /usr/local/ складируя там старые программы и библиотеки

Эм, а зачем? У меня обратное было, почему-то где-то /usr/local стоял в конце, а я его логично переставил в начало. Потому что у локальных бинарников именно этого компа приоритет очевидно должен быть выше чем у стандартных, иначе в них вообще нет смысла.

вы сами себе закладываете грабли на будущее в /usr/local/ складируя там старые программы и библиотеки

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

Возможно /srv/local/ подойдёт.

Десять лет назад, говорят, его вообще не было

и это правильно, /usr/local - зло

зло это неумение пользоваться инструментами.
не нравится usr/local/bin - сделай ее ссылкой на usr/bin

А /srv/* благо.

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

Может я один такой тупой, но я так делал именно когда было не очевидно почему я пишу «mc» а запускается что-то непотребное, которое сам же и собирал полгода назад, да забыл про него.

Пусть уж лучше по-умолчанию запускается то, что родное для дистрибутива, а остальное где я играл в программиста - руками допишу путь.

В ArchLinux это еще и не так просто было, если память не изменяет. Прям сильно надо захотеть, чтобы выкусить /usr/local из пути по-умолчанию.

Тогда незачем было его в /usr/local/bin класть. Это как раз место для запуска по имени файла без пути (другого смысла у этой директории нет), причём не локальное юзера, а общесистемное, но не от дистра. Локальное юзера это $HOME/bin и у меня оно ещё выше по приоритету по тем же причинам - если юзер хочет себе запуск файла без пути - очевидно он в курсе что может этим перебить какой-то системный бинарник.

Возможно /srv/local/ подойдёт.

В /tmp/local клади.

И вы вот честно, каждый раз, когда хотите поиграть в какие-нибудь исходники делаете руками --prefix=/tmp/local ? Это какой-то заоблачный уровень аккуратности )

У меня так и валяются какие-то запчасти, оказывается:

$ tcc -v
tcc version 0.9.27 (x86_64 Linux)

$ /usr/bin/tcc -v
tcc version 0.9.27 (x86_64 Linux)

$ /usr/local/bin/tcc -v
[0]: </usr/local/bin/tcc>
[1]: <-v>
First parse
[1] R: <-v>
tcc version 0.9.27 mob:da11cf6-mod (x86_64 Linux)

«Поиграть в исходники» это что?

Системные директории не место для свалки, это тот софт, который необходим для процесса пользования компьютером. Вот представь, что у компьютера есть системный администратор и есть пользователи. Администратор может по их заказу устанавливать какой-нить софт. Вот то, что он устанавливает - это в /, /usr, /usr/local. А то, что устанавливают пользователи для каких-то своих временных развлечений - в $HOME, потому что больше у них никуда доступа на запись нет и не должно быть. Ну, можно ещё в /tmp но это уже слишком.

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

«Поиграть в исходники» это что?

Это когда у кого-нибудь на ЛОРе щеки вот-вот лопнут - идёшь за исходниками и смотришь, как там на самом деле.

вообще даже насчет /usr в fhs написано расплывчатое «/usr is the second major section of the filesystem» :)
сколь помню sbin изначально расшифровывался «second bin» ибо был на второй дискетке разработчиков просто.