Diretórios padrão e / ou comuns em sistemas operacionais Unix / Linux


25

Vindo do mundo Windows, achei a maioria dos nomes de diretório de pastas bastante intuitivos:

  • \Program Files contém arquivos usados ​​por programas (surpresa!)

  • \Program Files (x86) contém arquivos usados ​​por programas de 32 bits em sistemas operacionais de 64 bits

  • \Users(anteriormente Documents and Settings) contém os arquivos dos usuários, como documentos e configurações

    • \Users\USER\Application Data contém dados específicos do aplicativo

    • \Users\USER\Documents contém documentos pertencentes ao usuário

  • \Windows contém arquivos que pertencem à operação do próprio Windows

    • \Windows\Fonts armazena arquivos de fonte (surpresa!)

    • \Windows\Temp é um diretório temporário global

et cetera. Mesmo se eu não tivesse idéia do que essas pastas faziam, eu poderia adivinhar com boa precisão seus nomes.

Agora, estou dando uma boa olhada no Linux e ficando bastante confuso sobre como encontrar o meu caminho no sistema de arquivos.

Por exemplo:

  • /bincontém binários. Mas assim como /sbin, /usr/bin, /usr/sbin, e provavelmente mais que eu não sei sobre. Qual e qual?? Qual a diferença entre eles? Se eu quiser criar um binário e colocá-lo em algum lugar do sistema, onde eu o coloco?

  • /mediacontém sistemas de arquivos de mídia externos. Mas o mesmo acontece /mnt. E nenhum deles contém nada no meu sistema no momento; tudo parece estar em /dev. Qual é a diferença? Onde estão as outras partições no meu disco rígido, como o C:e D:que estavam no Windows?

  • /homecontém os arquivos e configurações do usuário. Isso é intuitivo, mas, então, o que é suposto entrar /usr? E por que /rootainda está separado, mesmo que seja um usuário com arquivos e configurações?

  • /libcontém bibliotecas compartilhadas, como DLLs. Mas o mesmo acontece /usr/lib. Qual é a diferença?

  • O que é /etc ? Realmente significa "et cetera", ou algo mais? Que tipos de arquivos devem aparecer lá - global ou local? É uma coisa fácil para as coisas que ninguém sabia onde colocar, ou existe um caso de uso específico para isso?

  • Quais são /opt, /proce /var? O que eles representam e para que são usados? Não vi nada parecido no Windows * e simplesmente não consigo descobrir para que servem.

Se alguém puder pensar em outros lugares padrão que possam ser bons para conhecer, fique à vontade para adicioná-lo à pergunta; espero que isso possa ser uma boa referência para pessoas como eu, que estão começando a se familiarizar com os sistemas * nix.

* OK, isso é mentira. Eu já vi coisas semelhantes no WinObj, mas obviamente não regularmente. Ainda não sei o que eles fazem no Linux.


11
Obrigado por manter um bom espírito de aprendizado. Este tópico geralmente é controverso. Veja minha resposta a esta pergunta para obter explicações adicionais sobre as diferenças fundamentais entre as estruturas do sistema de arquivos no Windows e Linux.
Caleb

Não pense em "usr" como a abreviação de "user", mas em "Recursos do Sistema Unix" (mesmo que seja provavelmente um backronym, pois contém diretórios de usuários anos atrás) ( linux-training.be/files/books/html /fun/ch09s08.html ).
lgeorget

Não adianta tentar justificar o nome encriptado do diretório Unix / Linux / etc no Windows (ou no Mac OS X). É assim que é.
Andrew Wolfe

A partir de 2017, a estrutura de pastas do Windows está uma bagunça completa. C:\Program Files, C:\ProgramData, %HOME%\AppData\Local, %HOME%\AppData\LocalLow, C:\Windows\SystemApps... Todos os exemplos onde se pode encontrar executáveis no Windows. E nem vou falar sobre arquivos de configuração e registro, não quero ficar ainda mais deprimido. PS: Eu trabalho principalmente no Windows.
R17na #

Respostas:


29

As distribuições Linux usam o FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html

Você também pode tentar man hier.

Vou tentar resumir as respostas das minhas perguntas, mas sugiro fortemente que você leia a ESF:

  • / bin é para binários do sistema sem superusuário
  • / sbin é para binários do sistema superusuário (raiz)
  • / usr / bin e / usr / sbin destinam-se a binários compartilhados não críticos e não superusuário ou superusuário, respectivamente
  • / mnt é para montar temporariamente uma partição
  • / media é para montar várias mídias removíveis de uma só vez
  • / dev contém seus arquivos de dispositivo do sistema; é uma longa história :)
  • A pasta / usr e suas subpastas podem ser compartilhadas com outros sistemas, para que eles tenham acesso aos mesmos programas / arquivos instalados em um único local. Como o / usr geralmente está em um sistema de arquivos separado, ele não contém binários necessários para colocar o sistema online.
  • / root é separado porque pode ser necessário colocar o sistema online sem montar outros diretórios que possam estar em partições / discos rígidos / servidores separados
  • Sim, / etc significa "et cetera". Os arquivos de configuração para o sistema local são armazenados lá.
  • / opt é um local onde você pode instalar programas que você baixa / compila. Dessa forma, você pode mantê-los separados do resto do sistema, com todos os arquivos em um só lugar.
  • / proc contém informações sobre o kernel e processos em execução
  • / var contém arquivos de tamanho variável, como logs, correio, páginas da web etc.

Para acessar um sistema, geralmente você não precisa de / var, / opt, / usr, / home; alguns dos diretórios potencialmente maiores em um sistema.

Um dos meus favoritos, que algumas pessoas não usam, é / srv. É para dados que estão sendo hospedados por serviços como http / ftp / samba. Eu já vi / var muito usado para isso, o que não é realmente o seu propósito.


Boa visão geral, abordando questões específicas. Observe que algumas distribuições são usadas /home/users/usernamepara usuários e /home/services/servicenamepara o que você menciona /src. Eu acho que isso funciona melhor, pois é mais versátil para particionar. Você pode instalá-lo em sua própria partição ou usar a mesma partição e os dados do usuário, o que geralmente é o que eu quero fazer.
Caleb

+1 obrigado pelo link e pelas descrições, são incríveis! :)
Mehrdad

/ usr deve conter arquivos específicos para os aplicativos que estão no sistema operacional e / ou arquivos de terceiros. Não é intriniscalmente compartilhável! Embora o LSB defenda que estes sejam mantidos em / opt. O / usr / share, por outro lado, pode conter arquivos compartilháveis ​​em máquinas de diferentes versões de arquiteturas / sistemas operacionais. Estes são todos apenas convenções embora! É bem possível (apesar de muito trabalho) usar uma estrutura completamente diferente. Há outras convenções embora - como Arquitetura flexível Optimal da Oracle
symcbean

11
Outra coisa a ter em mente sobre o Unix é o conceito de que " tudo é um arquivo " (ou pelo menos se parece com um). Por exemplo, as coisas em / proc parecem arquivos e diretórios, mas o conteúdo é realmente criado dinamicamente pelo kernel quando você os acessa. Isso significa que você pode usar as mesmas ferramentas (sl, gato, etc.) para acessar essas informações.
KeithB

11
@symcbean No FHS: "... / usr é compartilhável, dados somente leitura. Isso significa que / usr deve ser compartilhável entre vários hosts compatíveis com FHS ...". Obviamente, alguns arquivos são dependentes da arquitetura e algumas distribuições esperam hierarquias de diretório muito diferentes. A solução é fazer sua lição de casa, como uma boa administração :)
bhinesley

18

Não vou responder sobre o que todos eles significam (outros têm), mas darei um pouco de contexto histórico.

Primeiro, lembre-se de que o UNIX está chegando aos 40 anos, nos dias de fita de papel e terminais codificados de 300 bauds nos mainframes (o sistema Windows XP tem quase 10 anos). A digitação foi lenta e a necessidade de eficiência na digitação superou muitas outras considerações. Essa é a razão dos comandos básicos muito curtos (por exemplo, 'ls', 'cat', 'cc', 'dd' etc.). O mesmo aconteceu com as estruturas de diretório. O pensamento era que, se o comando tivesse mais de três ou quatro caracteres, o nome seria muito longo.

O diretório / usr originalmente continha os diretórios pessoais do usuário, pois a maioria dos comandos estava em / bin e todos os arquivos do dispositivo estavam em / dev. Mais tarde, pensou-se que a unidade principal (o sistema de arquivos raiz, '/') fosse pequena para tempos de inicialização mais rápidos. Então outras estruturas como / usr / bin, / usr / include e / usr / lib surgiram, onde / usr era uma "unidade" separada. Muito mais tarde, pensava-se que os diretórios pessoais do usuário estavam em / home, mais uma unidade. E muito mais tarde, ter um / var (abreviação de variável / variável). O diretório / etc significava 'et cetera', pois esse era o local geral de todos os arquivos de configuração do sistema. O / mnt foi usado como um local temporário para acessar uma unidade (geralmente uma unidade de backup). Diretórios como / opt, / proc e / media vieram muito mais tarde.

Há muito o que ficar de fora (como / usr / local e / net), mas isso fornece uma breve descrição de por que os nomes são 'menos intuitivos'.


2
+1 Eu amo o contexto histórico, ele organiza meu cérebro. :) Obrigado por tomar o tempo para escrever isso!
Mehrdad

5

Como já mencionado aqui, as distribuições Linux usam principalmente o FHS; veja aqui uma visão geral do tutorial, especialmente adequada para quem vem do Windows.

Como uma observação, os diretórios do Windows parecem intuitivos, superficialmente. Mas deixe-me perguntar: onde pertencem as configurações de um programa, como um *.iniarquivo na pasta de programas, em Documents and Settings\User( \Application Dataou \Local Settings\Application Data) ou no infame registro? ninguém sabe, nem mesmo a Microsoft. E assim podemos continuar e continuar.


11
Eu acho que os nomes das pastas do Windows 7 são melhores. ou seja, AppData \ Roaming vs. AppData \ Local - eles descrevem o tipo de dados lá. Quanto às informações de configuração: acho que sei onde colocá-lo quando o vejo, mas não consigo descrevê-lo bem, concordo. :)
Mehrdad
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.