Почему в / bin есть сочетание символических ссылок и hardlinks?

Я понимаю техническую разницу между символическими ссылками и hardlinks, это вопрос их использования на практике, особенно мне любопытно узнать, почему оба используются в кажущихся схожих условиях: каталог /bin .

Вот фрагмент его списка в моей системе:

 ~$ ls -lai /bin total 10508 32770 drwxr-xr-x 2 root root 4096 Jun 14 11:47 . 2 drwxr-xr-x 28 root root 4096 Sep 6 13:15 .. 119 -rwxr-xr-x 1 root root 959120 Mar 28 22:02 bash 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bunzip2 127 -rwxr-xr-x 1 root root 1832016 Nov 16 2012 busybox 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bzcat 6191 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzcmp -> bzdiff 5640 -rwxr-xr-x 1 root root 2140 Dec 15 2011 bzdiff 5872 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzegrep -> bzgrep 3520 -rwxr-xr-x 1 root root 4877 Dec 15 2011 bzexe 6184 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzfgrep -> bzgrep 5397 -rwxr-xr-x 1 root root 3642 Dec 15 2011 bzgrep 2820 -rwxr-xr-x 3 root root 31112 Dec 15 2011 bzip2 2851 -rwxr-xr-x 1 root root 10336 Dec 15 2011 bzip2recover 6189 lrwxrwxrwx 1 root root 6 Dec 15 2011 bzless -> bzmore 5606 -rwxr-xr-x 1 root root 1297 Dec 15 2011 bzmore 

Я исказил жесткие ссылки в том же inode для лучшей видимости. Итак, символические bzcmp используются в случае bzcmp , bzegrep , bzfgrep , bzless и bzless в случае bzip2 , bzcat , bunzip2 ?

Это все обычные файлы (не каталоги), они находятся внутри одной файловой системы, являются системными утилитами и даже предназначены для работы с одним и тем же: архивы bzip. Являются ли причины для использования hardlinks / symlinks в данном конкретном случае чисто историческими или я что-то упускаю?

Уточнение моего вопроса:

Я не спрашиваю:

  • Технические различия между символическими ссылками и жесткими ссылками
  • Теоретические преимущества и недостатки каждого из них

Эти вопросы были рассмотрены в других потоках на SO. Я пытаюсь понять, почему в конкретном случае были приняты различные решения: для группы связанных системных утилит. Технически все они могли быть симлинками, или все они могли быть жесткими ссылками, оба варианта будут работать (и в обоих случаях программа все же может понять, как она была вызвана через argv[0] ). Я хочу понять намерение здесь, если оно есть.

Связанный:

  • Почему существуют жесткие связи?

  • Как редактировать символические ссылки?
  • Как создать командный ярлык для файла .sh?
  • Символы Nvidia Opengl
  • Почему «ls -L» печатает имя самой ссылки, а не имя файла, на который указывает ссылка?
  • Есть ли способ заменить значение символической ссылки?
  • создать символическую ссылку с ln, но будет создан цикл
  • Можно ли загрузить файл ссылки из веб-каталога?
  • Почему разрешение отклонено для запуска npm с использованием node-dev?
  • 2 Solutions collect form web for “Почему в / bin есть сочетание символических ссылок и hardlinks?”

    Зачем использовать ссылки hardlinks и Symbolic

    В этом сценарии есть в основном 3 преимущества использования hardlinks над символическими ссылками.

    Жесткие ссылки

    1. С жесткой ссылкой ссылка указывает на индексный дескриптор напрямую.
    2. Жесткие ссылки похожи на наличие нескольких копий исполняемого файла, но только с использованием дискового пространства одного.
    3. Вы можете переименовать любую ветвь жесткой ссылки, не нарушая ничего.

    Символические ссылки

    1. Ссылка указывает на объект (который затем в свою очередь указывает на индексный дескриптор).
    2. Они могут охватывать файловые системы, тогда как hardlinks не могут.

    Преимущества соединения в целом

    Эти ссылки существуют, потому что многие исполняемые файлы ведут себя по-разному в зависимости от того, как они были вызваны. Например, 2 команды bzless и bzmore на самом деле представляют собой один исполняемый файл, bzmore . Исполняемый файл будет вести себя по-разному в зависимости от того, какие имена были использованы для его вызова.

    Это делается по целому ряду причин. Вот некоторые из наиболее очевидных:

    1. Легче разработать один исполняемый файл, а не многие
    2. Сохраняет дисковое пространство
    3. Легче развертывать

    Почему оба используются?

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

    При взгляде на FHS (стандарт иерархии файловой системы) даже определяет его таким образом, что он может быть и.

    выдержка

    Если / bin / sh не является настоящей оболочкой Bourne, она должна быть жесткой или символической ссылкой на настоящую команду оболочки.

    Обоснование этого состоит в том, что sh и bash могут не обязательно вести себя одинаково. Использование символической ссылки также позволяет пользователям легко видеть, что / bin / sh не является настоящей оболочкой Bourne.

    Если существуют программы gunzip и zcat, они должны быть символическими или жесткими ссылками на gzip. / bin / csh может быть символической ссылкой на / bin / tcsh или / usr / bin / tcsh.

    Рекомендации

    • Почему ссылки на перезагрузку, выключение и poweroff на systemctl?

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

    Ответ в том, что другого правила нет. Этот пример, который вы указали из пакета bzip2 от Ubuntu, просто показывает, что многие разработчики смешивают их без большого количества предусмотрительности. Это связано с тем, что нет сильных указаний, кроме технических различий, и эти различия малы.

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

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

    Эта проблема очень похожа на пробелы против табуляции или динамическую или статическую типизацию или Emacs vs. vi , за исключением того, что она не достаточно интересна, чтобы вызвать священную войну . Как и более интересные битвы, есть причины выбрать любой вариант, но если у вас есть кто-то, говорящий вам, какой из них использовать, вы можете выбрать тот, который имеет больше смысла для вас.

    Linux и Unix - лучшая ОС в мире.