Как избежать коллизий команд?

никак, пусть ментейнеры мучаются.

my-pedantically-named-prog-is-unique

Вот мне не хочется давать командам бессмысленные или длинные имена. Хочется использовать понятные, при взгляде на которые человеку сразу будет понятно, какую функцию она выполняет.

git clone vs hg clone, например. А там уже пусть пользователь алиасы делает, если надо.

типа dd, tar и ed? :)

app-1bde13d9cb1675c5ca8188c8c86066c9

как то так.

Да. Ещё хотелось бы избежать бессмысленных ключей к командам, но с этим уже легче.

первая буква названия пакета_имя команды. Так, например, GROMACS делают, соответственно утилиты называются: g_rmsf, g_dist и т.д.

Как подстраховаться от ситуации совпадения команд для использования своей программы с командами других программ?

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

что произойдёт в системе в этом случае?

одна из них не будет запускать без указания полного пути. Ну или затрётся бинарь старой проге.

http://packages.debian.org/search?searchon=contents&keywords=my_cool_prog...

Команды программ... что всё это, факен шит, значит?

Автору темы мое замечание, увы, никак не поможет, но никак не могу пропустить такую возможность пожаловаться на отсутствие в gnu/linux вложенных путей в /bin и т.д.

Достаточно тривиально научить шелл считать любой путь из $PATH (а не только непосредственно файл в нем) именем команды.

Тогда, для того же hg, мы могли бы иметь директорию /usr/bin/hg с файлами pull, update и т.д., и вызывались бы они, при наличии /usr/bin в $PATH, как hg/pull, hg/update и т.д.

Таким образом, исключаются конфликты имен; более того, при желании можно иметь несколько наборов команд — скажем, разных версий: hg/pull и hg-new/pull.

Почему этого нет — непонятно. Пример системы, успешно такое соглашение использующей — Plan 9. Все команды там сгруппированы в каталоги, входящие в /bin, например, команды, работающие с дисками, лежат в /bin/disk, набор команд replica (похоже на rsync, интерфейс разделен на команды в стиле vcs) — в /bin/replica.

«C:\program files\...», не?

Хорошая идея, но я такой сизифов труд не осилю :)

А что такое «команды программ»? Это функции какой-то библиотеки, или же это - бинарники?

Бинарники.

На самом деле оно и в Linux встречается, но чрезвычайно редко:

[~] >> ls /usr/bin/mh
ali    flist    inc         mhmail   mhstore  pick      rmf        show
anno   flists   install-mh  mhn      msgchk   prev      rmm        sortm
burst  folder   mark        mhparam  msh      prompter  scan       whatnow
comp   folders  mhbuild     mhpath   next     refile    send       whom
dist   forw     mhlist      mhshow   packf    repl      sendfiles

Этот пакет пишет свой /usr/bin/mh в PATH?

А разве нельзя модифицировать пакет, отвечающий за сканирование PATH так, чтобы он мог переваривать пути вида /usr/*/bin?

>> Этот пакет пишет свой /usr/bin/mh в PATH?

Нет.

А разве нельзя модифицировать пакет, отвечающий за сканирование PATH так, чтобы он мог переваривать пути вида /usr/*/bin?

Можешь генерировать $PATH функцией вместо явного присваивания. Только проблему коллизий это никоим образом не решит.

>Нет.

А как тогда?

>> А как тогда?

Пользователь может модифицировать свой личный $PATH (либо сделать алиасы) сам :] Системный трогать плохо.

А мне всегда интересно было, но не проверял никогда: лежат четыре разных бинарника с одинаковыми именами в /bin, /sbin, /usr/bin и /usr/sbin соответственно. Если в терминале исполнить команду без явного указания, откуда брать бинарник откуда исполнится?
Ставлю всё на /bin. Скажите, что я не прав.

man bash

Ставлю всё на /bin. Скажите, что я не прав.

В общем случае это не так.

> Ставлю всё на /bin. Скажите, что я не прав.
В документации четко напиcано: бинарники ищются в папках из $PATH по порядку: /usr/local/bin:/usr/bin:/bin: ...

Как порядок изменить?

Очевидно, поменять пути местами.

это же вроде особенность конкретно rc, а не Plan 9 вообще? может просто порт rc заюзать вместо bash? ну или bash пропатчить, думаю, это несложно. опять же, может zsh через какой-нибудь плагин умеет?

Путь запуска something/somecommand согласно POSIX трактуется как ./something/somecommand

> Путь запуска something/somecommand согласно POSIX трактуется как ./something/somecommand

ну, есть же Леннарт, пусть предложит ввести соответствующую поправку в POSIX

> Тогда, для того же hg, мы могли бы иметь директорию /usr/bin/hg с файлами pull, update и т.д., и вызывались бы они, при наличии /usr/bin в $PATH, как hg/pull, hg/update и т.д.

В чём разница между hg/pull и hg-pull?

> В чём разница между hg/pull и hg-pull?

Кроме различных эстетических различий (например, все, относящееся к mercurial, не лежит в каше в /bin), разница, например, в том, что у hg/pull basename — «pull», а у hg-pull — «hg-pull». Многие программы чувствительны к своему basename (маргинальный пример — busybox, но очень много что, например, понимает «r» в начале basename как признак запуска «безопасной» версии, например, rvi).

> git clone vs hg clone, например. А там уже пусть пользователь алиасы делает, если надо.

Ну имена пакетов могут совпасть, хоть вероятность этого и сильно меньше.

иметь директорию /usr/bin/hg с файлами pull, update и т.д., и вызывались бы они, при наличии /usr/bin в $PATH, как hg/pull, hg/update

Не нужно:

#cat /usr/bin/hg
#!/bin/sh
exec /usr/libexec/hg/"$@"