zsh находится в/usr/bin, но также и в / мусорном ведре, каково различие?

У меня была та же проблема, и Ваш вопрос на самом деле выручил меня много. Я пытался удалить первый (p7zip_compress2) после того, как я проверил, что в файле он имел те же записи как остальная часть .desktop файлов... Поэтому удалите его и решенный! никакая потребность перезапустить или что-либо

6
04.04.2013, 23:01
6 ответов

Каждый - вероятно, символьная ссылка (или жесткая ссылка) к другой....., но они - ТОТ ЖЕ файл.

7
27.01.2020, 20:20
  • 1
    Для проверки использовать ls -l. Если Вы будете ссылкой другого, то Вы будете видеть linkedName -> /path/targetName –  kmort 05.04.2013, 00:09
  • 2
    @kmort, который Это только проверит, является ли это символьная ссылка. Для hardlink, в ls -l вывод, Вы будете видеть число каналов> 1, и если Вы stat их, inode число будет тем же. –  derobert 05.04.2013, 00:18
  • 3
    @mdpc Предлагает, чтобы Вы добавили информацию от kmort и моих комментариев к Вашему ответу. –  derobert 05.04.2013, 00:19
  • 4
    На самом деле они оба - ссылки на /bin/zsh4, то, что я думаю, является фактической оболочкой. Благодаря всем для их ответов! –  brgr 05.04.2013, 19:50

Содержание /etc/shells более или менее статичны и не имеют никакого отношения к присутствию определенных оболочек, установленных в системе.

То, что существует две записи в Вашем /etc/shells средства только это, если пользователь имеет также /bin/zsh или /usr/bin/zsh указанный как их оболочка в /etc/passwd, их обоих считали бы 'допустимыми' демоны, которые консультируются /etc/shells (например, большинство демонов FTP).

Для наблюдения первого доступного zsh в пути ($PATH), можно использовать, которые управляют как это:

which zsh

Или whereis, который отображает больше информации (двоичный файл, источник и файлы страницы руководства для команды):

whereis zsh
8
27.01.2020, 20:20

Когда /bin/zsh существует, избыточное существование /usr/bin/zsh имеет главным образом цель мобильности в том смысле, что Вы не должны редактировать каждого и строку хижины любых сценариев, который, при использовании zsh, вероятно, обратится /usr/bin/zsh.

zsh не считается стандартным программным обеспечением, но многие и еще больше людей используют его, даже жесткие системные администраторы. И вот почему больше дистрибутивов имеет тенденцию помещать его в /bin/zsh также.

Переходить к сути дела: это не a zsh проблема, но функция, которая должна гарантировать, что загрузила Linux (или исторически, Unix) система в определенное состояние.

/bin определяется для нахождения в корневой файловой системе, в то время как /usr/bin не.

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

Таким образом, при начальной загрузке системы без сетевой поддержки, или в случае, если сеть понижается случайно, или когда диск отказывает или файловая система повреждается, или просто загружающийся в однопользовательский режим, не монтируя ничего, файлов в /bin все еще доступны.

То же относится /lib и /usr/lib: на самом деле, что-либо вне /usr как полагают, не жизненно важен для базовой системы (также X11 обычно находится где-нибудь в /usr ответвление. И это - также причина, почему $HOME корня не /home/root, с тех пор /home как также полагают, не находится в корневой файловой системе.

И если разрушенный системный диск? Или корневая файловая система повреждается? Ну, затем возможности состоят в том, что Вы не можете равномерная нагрузка ядро...

Большая часть вышеупомянутого не слишком очень важна для сегодняшних систем. NFS смонтирован /usr/* файловые системы являются ненужными, так как дисковое пространство является дешевым и доступным в огромном количестве.

Даже изображения ОС установлены на отдельном /boot файловая система во многих установках, так, чтобы загрузка ядра не гарантировала, что смогла смонтировать корневую файловую систему, но для этого, мы имеем initrd в эти дни, который содержит рабочую начальную корневую файловую систему для запуска ядра (в который, на самом деле, zsh будет отсутствовать в большинстве случаев).

Это - также обычная практика, чтобы иметь большую корневую файловую систему, которая включает /usr ответвление, которое имеет некоторые преимущества при клонировании установок.

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

(это было больше в стороне, но это факты),

5
27.01.2020, 20:20

По причинам совместимости. Некоторые сценарии используют / мусорное ведро использования/usr/bin других. Несколько дистрибутивов хотят переместить все в/usr/bin, так как нет большого количества точки в наличии/sbin и / мусорном ведре больше. Одним из исключений является удар с тех пор #!/bin/bash использовался в бесчисленных сценариях за прошлые десятилетия, таким образом обеспечивая/bin/bash для совместимости, с символьной ссылкой, хорошее решение на данный момент.

0
27.01.2020, 20:20

они могут быть одинаковыми (проверьте размеры файлов с помощью ls -l) или / bin / zsh может быть статически связанной версией

в моем debian jessie стенд такие же, но я мог бы поиграть с альтернативами обновления , чтобы сделать / bin / sh ссылкой на / bin / zsh-static

в случае, если в моей системе отсутствует какая-либо зависимость ссылки zsh, я мог бы для входа в систему, если моя оболочка / bin / zsh (если она связана с / bin / zsh-static)

эта практика является нормой для систем Solaris, где / bin / ksh - облегченная версия оболочки korn, где тяжелая версия со всеми функциями находится в / usr / bin / ksh

/ usr / bin предшествует / bin / в пути, поэтому, если вы не укажете, какой из них вы хотите, вы получите лучшую оболочку по умолчанию

0
27.01.2020, 20:20
$ ls -li /bin/zsh /usr/bin/zsh
19401918 -rwxr-xr-x 1 root root 861568 Feb  4  2019 /bin/zsh
19401918 -rwxr-xr-x 1 root root 861568 Feb  4  2019 /usr/bin/zsh

Совпадение i -узлов означает, что они жестко -связаны.

1
27.01.2020, 20:20

Теги

Похожие вопросы