configuration: por que não conf option = nome do arquivo e valor do conf = conteúdo do arquivo [closed]

Question

Por que um dos paradigmas do Unix é salvar o nome da configuração (também conhecido como nome do atributo) e o valor da configuração nos arquivos de configuração?
Uma alternativa é salvar o nome do atributo no nome do arquivo e apenas o valor de configuração dentro do arquivo, seguindo o princípio KISS (mantenha-o simples e estúpido). A classificação de arquivos de configuração ainda pode ser feita com pastas. Até onde sei, algo semelhante já está implementado com alguns arquivos dentro do / proc no linux, embora eu nunca tenha visto isso em nenhum outro lugar.
Tanto quanto me lembro, a filosofia do Unix diz: "Tudo é um arquivo". Por que não aqui?

    

Answer 1

Alguns pensamentos aqui sobre por que os arquivos de configuração não são explodidos, opção por opção em um formato como:

config
    default
        key
        key
        ...
        key
    other
        key
        key
        ...

onde o primeiro subdiretório é um tipo de configuração e cada arquivo dentro ('key's here) são todas opções de configuração separadas, cada uma com um valor que é o conteúdo do arquivo. Todos esses pontos são apenas coisas que aprendi ao longo do caminho, e certamente existem muitas exceções.

1. Em geral, a maioria dos utilitários UNIX / Linux opera em um único arquivo por vez, linha por linha , e não em vários arquivos. Por quê? Muitas razões, mas esta parece ser a maneira mais simples de lidar com a entrada. A maioria dos arquivos quando vistos de uma interface de programação são apenas uma série de linhas. Linhas (algum texto seguido por um fluxo de linha ASCII \n ) são realmente a unidade mais básica de dados na maioria dos aplicativos, não em arquivos. ÁREA: Considere que o seu terminal foi projetado para ser impresso em papel, linha por linha, enquanto o usuário trabalhava. Honestamente, não mudou muito no moderno tty , pois ainda é tratado como uma interface serial.

2. Considere uma situação em que há muitas e muitas opções de configuração para um programa complexo, como um servidor de soquete ou outro daemon. Para que o programa tenha que abrir centenas de arquivos para procurar possíveis derivações dos padrões incorre em duas penalidades, um limite de descritor de arquivo aberto (fácil de contornar) e um par de syscalls por arquivo. O syscalls pode somar porque um programa precisa pedir ajuda ao kernal para ler e abrir arquivos.

3. Atualizar e editar um arquivo geralmente é muito mais simples de fazer com editores tradicionais (dos quais ed é o vencedor claro: D) ou utilitários como sed e awk . Usar ferramentas tradicionais de edição em um host de opções de configuração baseadas em arquivos seria realmente inconveniente. Também pesquisar sobre muitas opções se tornaria um exercício para o shell de um usuário e não o realmente possível para um editor. Se a maioria das opções de configuração fossem apenas valores simples, echo e alguns redirecionamentos de IOs seriam o editor de escolha (o que, se eu entender suas preferências, pode não ser tão ruim assim).

4. Comentários. Arquivos de configuração podem ser mais comentários do que opção, e eu realmente gosto de comentários. Se os arquivos de configuração foram trocados por diretórios de configuração, é melhor que as pessoas se acostumem a fazer arquivos README e, de repente, temos um desagradável arquivo baseado em linhas lá;)

Em geral, eu diria que a configuração baseada em arquivos é apenas nos ossos dos sistemas UNIX / Linux. Poderia ser feito de uma maneira diferente? Certo. O paradigma atual é o melhor caminho? Pode ser para sistemas UNIX / Linux, mas não para outro ambiente em que os diretórios substituem arquivos como o ponto de interface com a entrada.

    

Answer 2

Considere o editor de texto amplamente utilizado Vim. O Vim tem mais de 360 opções, mais muitas outras funcionalidades que podem ser configuradas de várias maneiras. Quando o Vim é inicializado, ele lê um punhado de arquivos de inicialização - um arquivo de inicialização do sistema, um ou dois arquivos de inicialização específicos do usuário, possivelmente vários outros arquivos que configuram realce de sintaxe, menus e assim por diante. Com sua configuração proposta, o Vim precisaria procurar (ou seja, tentar abrir) mais de 360 arquivos de configuração de opções em todo o sistema, seguidos por 360 arquivos de configuração de opções específicos do usuário, e ainda precisa ler os arquivos de configuração regulares, porque o Vim é scriptável e as funcionalidades mais interessantes são configuradas usando a linguagem de script. Tentar abrir muitas centenas de arquivos apenas para lançar um editor de texto seria bastante ineficiente.

E agora vêm os problemas reais. Algumas opções podem ser definidas para valores que dependem de outras opções; em um arquivo de configuração regular que é fácil - apenas certifique-se de colocá-los na ordem correta. Com a configuração proposta, não há como garantir que, por exemplo, a opção "compatível" seja definida antes de "backspace". Em um arquivo de configuração regular, o usuário pode usar a linguagem de script para adaptar os valores de certas opções ao ambiente operacional; isso seria estranho fazer na sua configuração.

O que você está descrevendo é, na verdade, o registro do Windows. Há uma razão pela qual o registro é armazenado como um tipo de banco de dados e não como um grande número de arquivos minúsculos.