Стандартные и / или общие каталоги в ОС Unix / Linux


25

Исходя из мира Windows, я обнаружил, что большинство имен каталогов папок интуитивно понятны:

  • \Program Files содержит файлы, используемые программами (сюрприз!)

  • \Program Files (x86) содержит файлы, используемые 32-разрядными программами в 64-разрядных ОС

  • \Users(ранее Documents and Settings) содержит файлы пользователей, то есть документы и настройки

    • \Users\USER\Application Data содержит данные для конкретного приложения

    • \Users\USER\Documents содержит документы, принадлежащие пользователю

  • \Windows содержит файлы, которые относятся к работе самой Windows

    • \Windows\Fonts хранит файлы шрифтов (сюрприз!)

    • \Windows\Temp это глобальный временный каталог

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

Теперь я хорошо смотрю на Linux и не совсем понимаю, как найти путь к файловой системе.

Например:

  • /binсодержит двоичные файлы Но так делать /sbin, /usr/bin, /usr/sbinи , вероятно , больше , что я не знаю , о. Что есть что ?? В чем разница между ними? Если я хочу сделать бинарный файл и поместить его где-нибудь в масштабе всей системы, куда мне его поместить?

  • /mediaсодержит внешние медиа-файловые системы. Но так же /mnt. И ни один из них не содержит ничего в моей системе в данный момент; кажется, все в /dev. Какая разница? Где другие разделы на моем жестком диске, такие как C:и D:которые были в Windows?

  • /homeсодержит пользовательские файлы и настройки. Это интуитивно понятно, но во что же тогда верить /usr? И почему /rootже все еще отдельно, даже если это пользователь с файлами и настройками?

  • /libсодержит общие библиотеки, такие как библиотеки DLL. Но так же /usr/lib. Какая разница?

  • Что это /etc ? Это действительно означает «и так далее» или что-то еще? Какие типы файлов должны быть там - глобальные или локальные? Является ли это универсальным для вещей, которые никто не знал, где поставить, или есть конкретный вариант использования для этого?

  • Что /opt, /procи /var? За что они стоят и для чего они используются? Я не видел ничего подобного в Windows *, и я просто не могу понять, для чего они могут быть.

Если кто-то может подумать о других стандартных местах, о которых было бы полезно узнать, не стесняйтесь добавить его к вопросу; надеюсь, это может быть хорошим справочником для таких людей, как я, которые начинают знакомиться с * nix системами.

* ОК, это ложь. Я видел подобные вещи в WinObj, но, очевидно, не на регулярной основе. Я все еще не знаю, что они делают на Linux, хотя.


1
Спасибо за сохранение хорошего духа обучения. Эта тема часто спорная. Смотрите мой ответ на этот вопрос для некоторых дополнительных объяснений фундаментальных различий между структурами файловой системы в Windows и Linux.
Калеб

Не думайте, что «usr» - это аббревиатура «user», а «системные ресурсы Unix» (даже если это, вероятно, обратный термин, поскольку он действительно содержал каталоги пользователей много лет назад) ( linux-training.be/files/books/html /fun/ch09s08.html ).
lgeorget

Нет смысла пытаться оправдать использование загадочных имен каталогов Unix / Linux / etc в Windows (или Mac OS X). Просто так оно и есть.
Эндрю Вульф

Начиная с 2017 года структура папок Windows представляет собой полный беспорядок. C:\Program Files, C:\ProgramData, %HOME%\AppData\Local, %HOME%\AppData\LocalLow, C:\Windows\SystemApps... Все примеры , где можно найти исполняемые файлы в Windows. И я даже не буду говорить о конфигурационных файлах и реестре, я не хочу быть еще более подавленным. PS: я работаю в основном в Windows.
17

Ответы:


29

В дистрибутивах Linux используется FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html

Вы также можете попробовать man hier.

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

  • / bin для не-суперпользовательских системных программ
  • / sbin - для суперпользовательских (корневых) системных двоичных файлов
  • / usr / bin & / usr / sbin для некритических совместно используемых двоичных файлов не-суперпользователя или суперпользователя соответственно
  • / mnt для временного монтирования раздела
  • / media предназначен для монтирования множества сменных носителей одновременно
  • / dev содержит файлы вашего системного устройства; это долгая история :)
  • Папка / usr и ее подпапки могут использоваться совместно с другими системами, чтобы у них был доступ к тем же программам / файлам, установленным в одном месте. Поскольку / usr обычно находится в отдельной файловой системе, он не содержит двоичные файлы, необходимые для перевода системы в оперативный режим.
  • / root является отдельным, потому что может потребоваться перевести систему в оперативный режим без подключения других каталогов, которые могут находиться на отдельных разделах / жестких дисках / серверах
  • Да, / etc означает «и так далее». Файлы конфигурации для локальной системы хранятся там.
  • / opt - это место, где вы можете устанавливать загружаемые / компилируемые программы. Таким образом, вы можете хранить их отдельно от остальной системы со всеми файлами в одном месте.
  • / proc содержит информацию о ядре и запущенных процессах
  • / var содержит файлы переменного размера, такие как журналы, почта, веб-страницы и т. д.

Для доступа к системе вам обычно не нужны / var, / opt, / usr, / home; некоторые из потенциально крупнейших каталогов в системе.

Один из моих любимых, который некоторые люди не используют, это / srv. Это для данных, которые размещаются через такие сервисы, как http / ftp / samba. Я видел, что / VAR использовал для этого много, что на самом деле не его цель.


Хороший обзор по конкретным вопросам. Обратите внимание, что некоторые дистрибутивы используются /home/users/usernameдля пользователей и /home/services/servicenameдля чего вы упоминаете /src. Я думаю, что это работает лучше, потому что это более универсально для разделения. Вы можете разместить его в своем собственном разделе или использовать тот же раздел и свои пользовательские данные, что я часто и хочу делать.
Калеб

+1 спасибо за ссылку и описания, они потрясающие! :)
Мердад

/ usr должен содержать файлы, относящиеся к приложениям, работающим в операционной системе, и / или сторонние файлы. Это не внутренне разделено! Хотя LSB утверждает, что они хранятся в / opt. С другой стороны, / usr / share может содержать файлы, которые могут использоваться на разных машинах разных версий / версий ОС. Это все просто соглашения, хотя! Вполне возможно (хотя и много тяжелой работы) использовать совершенно другую структуру. Однако существуют и другие соглашения - например, Оптимальная гибкая архитектура Oracle
symcbean,

1
Еще одна вещь, о которой нужно помнить о Unix, это концепция, что « все является файлом » (или, по крайней мере, выглядит как один). Например, содержимое в / proc выглядит как файлы и каталоги, но содержимое действительно создается ядром динамически при доступе к ним. Это означает, что вы можете использовать те же инструменты (ls, cat и т. Д.) Для доступа к этой информации.
KeithB

1
@symcbean Из FHS: «... / usr - это общедоступные данные только для чтения. Это означает, что / usr должен делиться между различными хостами, совместимыми с FHS ...». Очевидно, что некоторые файлы зависят от архитектуры, а некоторые дистрибутивы ожидают совершенно разных иерархий каталогов. Решение состоит в том, чтобы сделать свою домашнюю работу, как хороший администратор :)
bhinesley

18

Я не буду отвечать о том, что они все имеют в виду (у других есть), но приведу небольшой исторический контекст.

Во-первых, помните, что UNIX приближается к 40 годам, во времена бумажной ленты и жестко закодированных терминалов на скорости 300 бод для мэйнфреймов (системе Windows XP уже почти 10 лет). Печатание было медленным, и потребность в эффективности при печати перевешивала множество других соображений. Это является причиной очень коротких базовых команд (например, «ls», «cat», «cc», «dd» и т. Д.). То же самое было со структурами каталогов. Мысль была о том, что если команда содержит более трех или четырех символов, то имя было слишком длинным.

Каталог / usr изначально содержал домашние каталоги пользователя, так как большинство команд были в / bin, а все файлы устройств были в / dev. Позднее считалось, что основной диск (корневая файловая система, /) будет маленьким для ускорения загрузки. Так появились другие структуры, такие как / usr / bin, / usr / include и / usr / lib, где / usr был отдельным «диском». Намного позже считалось, что домашние каталоги пользователей находятся в / home, а это еще один диск. И намного позже этого, чтобы иметь / var (сокращение от переменной / заменяемой). Каталог / etc действительно имел в виду «и так далее», так как это было общее расположение всех файлов конфигурации системы. / Mnt использовался как временное место для доступа к диску (часто к резервному диску). Каталоги типа / opt, / proc и / media появились намного позже.

Здесь многое упущено (например, / usr / local и / net), но это дает краткое описание того, почему имена «менее интуитивны».


2
+1 Я люблю исторический контекст, он организует мой мозг. :) Спасибо, что нашли время, чтобы написать это!
Мердад

5

Как уже упоминалось здесь, в дистрибутивах Linux в основном используется FHS, см. Здесь обзор, подобный учебному пособию, особенно подходящий для тех, кто работает в Windows.

Как примечание, каталоги Windows кажутся интуитивно понятными, внешне. Но позвольте мне спросить вас, где находятся настройки для программы, как *.iniфайл в папке программ, в Documents and Settings\User( \Application Dataили \Local Settings\Application Data) или в печально известном реестре? никто не знает, даже Microsoft. И так мы можем продолжать и продолжать.


1
Я думаю, что Windows 7 имена папок лучше. то есть AppData \ Roaming vs. AppData \ Local - они описывают тип данных там. Что касается информации о конфигурации: я думаю, что знаю, куда ее поместить, когда увижу, но я не могу описать это хорошо, я согласен. :)
Mehrdad
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.