Чому в / bin існує поєднання символьних посилань та жорстких посилань?

Я розумію технічну різницю між посиланнями і жорсткими посиланнями, це питання щодо їх використання на практиці, особливо мені цікаво знати, чому обидва використовуються у, здавалося б, подібних умовах: /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, bzegrep, bzfgrep, bzlessі жорстких посилань в разі bzip2, bzcat, bunzip2?

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

Уточнення мого питання:

Я не питаю про:

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

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

Пов'язані:

• Чому існують жорсткі посилання?

Навіщо використовувати жорсткі посилання проти символічних посилань

В основному є три переваги використання жорстких посилань над символічними посиланнями в цьому сценарії.

Жорсткі посилання

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

Символічні посилання

1. Посилання вказує на об’єкт (який потім по черзі вказує на inode).
2. Вони можуть охоплювати файлові системи, тоді як жорсткі посилання не можуть.

Переваги зв’язування загалом

Ці посилання існують через те, що багато виконуваних файлів поводяться по-різному залежно від того, як їх називали. Наприклад, 2 команди bzlessі bzmoreнасправді один виконуваний, bzmore. Виконавчий файл буде вести себе по-різному, залежно від того, які імена використовувалися для його виклику.

Робиться це з різних причин. Ось кілька більш очевидних:

1. Простіше розробити єдиний виконуваний файл, ніж багато
2. Економить місце на диску
3. Легше розгортати

Чому обидва використовуються?

Вибір будь-якого, у цій конкретній програмі, суперечливий. Будь-яке може полегшити функцію псевдоніму, так що один виконуваний файл може бути перевантажений. Це дійсно ключова особливість, яку отримують розробники різних програм тут.

Дивлячись на FHS (стандарт ієрархії файлової системи) навіть конкретизує його таким чином, що він може бути будь-яким.

витяг

Якщо / bin / sh не є справжньою оболонкою Bourne, вона повинна бути твердим або символічним посиланням на реальну команду shell.

Обґрунтування цього полягає в тому, що sh та bash не обов'язково повинні вести себе однаково. Використання символічного посилання також дозволяє користувачам легко бачити, що / bin / sh не є справжньою оболонкою Bourne.

...

...

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

Список літератури

• Чому перезавантаження, вимкнення та переключення потужності посилаються на systemctl?

Здається, ви намагаєтеся з’ясувати з існуючої практики, чи існує нетехнічне правило, яке говорить вам, яке посилання використовувати. (Я кажу нетехнічно, тому що ви вже знаєте технічні причини використовувати одну над іншою.)

Відповідь - іншого правила немає. Цей приклад, який ви вказали з bzip2пакету Ubuntu, просто показує, що багато розробників змішують їх без усілякої задумки. Це тому, що немає жодних сильних вказівок, крім технічних відмінностей, і ці відмінності невеликі.

Особисто я вважаю за краще використовувати символьні посилання завжди, тому що я готовий платити за їхні крихітні накладні витрати в обмін на їх самодокументацію.

Інші розробники виберуть жорсткі посилання для мініатюрної ефективності, яку вони забезпечують.

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