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


10

Я понимаю техническое различие между символическими и жесткими ссылками, это вопрос об их использовании на практике, особенно мне интересно знать, почему оба они используются в, казалось бы, похожих условиях: /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

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

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

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

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

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

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

Связанные с:


Я думаю, что это должны решать разработчики пакета. Например, я запускаю gentoo, и в моем /binтретьем столбце ls -laiвсегда 1используется только мягкие ссылки. Какой дистрибутив вы используете?
повтор

Я пользуюсь Ubuntu 12.04
Дмитрий Пашкевич

1
На первый взгляд это выглядит как правило: «жесткие ссылки для двоичных файлов, символические ссылки для скриптов / оболочек» .
Петер

Ответы:


5

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

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

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

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

Символьные ссылки

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

Преимущества ссылок в целом

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

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

  1. Проще разработать один исполняемый файл, а не много
  2. Экономит дисковое пространство
  3. Проще развернуть

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

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

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

выдержка

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

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

...

...

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

Ссылки


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

@DmitryPashkevich - Хорошо, я изменил свой ответ, дайте мне знать, если это лучше.
SLM

Возможно, я задаю тупой вопрос, но чувствую, что он все еще остается без ответа :) Да, я знаком с техническими различиями и преимуществами / недостатками двух видов ссылок. Я пытаюсь понять конкретный случай: почему я вижу ОБА жесткие и символические ссылки в моем /bin/каталоге? Почему разработчики этих утилит не придерживаются одного типа ссылок?
Дмитрий Пашкевич

Отредактировал мой оригинальный вопрос, чтобы (надеюсь) прояснить его
Дмитрий Пашкевич

@DmitryPashkevich - добавлен дополнительный контент. Дайте мне знать, если это поможет.
СЛМ

5

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

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

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

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

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


1
Спасибо, что поделились своей точкой зрения! Я думаю, что «самодокументируемая» природа символических ссылок часто упускается из виду
Дмитрий Пашкевич
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.