У меня была та же проблема, и Ваш вопрос на самом деле выручил меня много. Я пытался удалить первый (p7zip_compress2) после того, как я проверил, что в файле он имел те же записи как остальная часть .desktop файлов... Поэтому удалите его и решенный! никакая потребность перезапустить или что-либо
Каждый - вероятно, символьная ссылка (или жесткая ссылка) к другой....., но они - ТОТ ЖЕ файл.
Содержание /etc/shells
более или менее статичны и не имеют никакого отношения к присутствию определенных оболочек, установленных в системе.
То, что существует две записи в Вашем /etc/shells
средства только это, если пользователь имеет также /bin/zsh
или /usr/bin/zsh
указанный как их оболочка в /etc/passwd
, их обоих считали бы 'допустимыми' демоны, которые консультируются /etc/shells
(например, большинство демонов FTP).
Для наблюдения первого доступного zsh в пути ($PATH), можно использовать, которые управляют как это:
which zsh
Или whereis, который отображает больше информации (двоичный файл, источник и файлы страницы руководства для команды):
whereis zsh
Когда /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
(и т.п.) немного устарели, но все еще реализованы в недавних системах.
(это было больше в стороне, но это факты),
По причинам совместимости. Некоторые сценарии используют / мусорное ведро использования/usr/bin других. Несколько дистрибутивов хотят переместить все в/usr/bin, так как нет большого количества точки в наличии/sbin и / мусорном ведре больше. Одним из исключений является удар с тех пор #!/bin/bash
использовался в бесчисленных сценариях за прошлые десятилетия, таким образом обеспечивая/bin/bash для совместимости, с символьной ссылкой, хорошее решение на данный момент.
они могут быть одинаковыми (проверьте размеры файлов с помощью 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 / в пути, поэтому, если вы не укажете, какой из них вы хотите, вы получите лучшую оболочку по умолчанию
$ 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 -узлов означает, что они жестко -связаны.
ls -l
. Если Вы будете ссылкой другого, то Вы будете видетьlinkedName -> /path/targetName
– kmort 05.04.2013, 00:09ls -l
вывод, Вы будете видеть число каналов> 1, и если Выstat
их, inode число будет тем же. – derobert 05.04.2013, 00:18/bin/zsh4
, то, что я думаю, является фактической оболочкой. Благодаря всем для их ответов! – brgr 05.04.2013, 19:50