Help:Reading (Português)

Porque a vasta maioria do ArchWiki contém indicações que podem precisar de clarificação para usuários novos ao Arch Linux (ou GNU/Linux em geral), esse resumo de procedimentos básicos foi escrito para evitar confusão na assimilação dos artigos e para evitar repetição de conteúdo.

Status de tradução: Esse artigo é uma tradução de Help:Reading. Data da última tradução: 2022-08-04. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Organização

A maioria dos artigos no ArchWiki não tentam fornecer uma introdução holística a um único tópico; eles são escritos em conformidade ao princípio DRY ("Não se repita"), sob a presunção de que o usuário vai buscar e ler qualquer material de suporte que ele ainda não entenda. Quando possível, tal material de suporte é indicado no artigo por um formato especial, veja #Formatação.

Por causa dessa organização, pode ser necessário examinar diversas fontes pra entender completamente um artigo do ArchWiki. Em particular, usuários que são novos no Arch (ou GNU/Linux em geral) devem esperar acabar lendo um grande número de artigos mesmo para resolver problemas simples. É especialmente importante estudar o material de suporte antes de procurar por ajuda adicional de outros usuários.

Formatação

• link para uma seção no artigo atual: #Organização
• link para outro artigo do ArchWiki
• link para uma página web externa
• link para uma página man: intro(1)
• uma página man que está disponível offline: foo(1)
• link para um pacote nos repositórios oficiais: foobar
• link para um pacote no AUR: foobar^AUR

Usuário comum ou root

Algumas linhas são escritas assim:

# mkinitcpio -p linux

Outras possuem um prefixo diferente:

$ makepkg -s

O sinal de cerquilha ou tralha (#) indica que o comando precisa ser executado como o superusuário (root), sendo que o sinal de cifrão ($) mostra que o comando deve ser executado como um usuário comum.

Nota: Os comandos prefixados com # destinam-se a serem executados de um shell de root, que pode, por exemplo, ser facilmente acessada com sudo -i. Executar sudo comando de um shell sem privilégios em vez de comando de um shell de root também funcionará na maioria dos casos, com algumas exceções notáveis como redirecionamento e substituição de comando, que requer estritamente um shell de root. Veja também sudo.

Uma exceção notável para ter cuidado com:

# Esse alias faz o ls colorizar a listagem
alias ls='ls --color=auto'

Neste exemplo, o contexto do sinal de cerquilha comunica que isso não deve ser executado como um comando; em vez disso, deve ser editado em um arquivo. Então, neste caso, o sinal de cerquilha representa um comentário. Um comentário pode ser um texto explicativo que não será interpretado pelo programa associado. A denotação de scripts Bash para comentário se parece com o PS1 de root.

Após uma observação mais detalhada, nota-se que os comentários geralmente se iniciam com caractere maiúsculos logo após o sinal #. Geralmente, comandos Unix não são escritos desta forma e, na maioria das vezes, elas são abreviações em vez de palavras completas em inglês (ex.:, Copy se torna cp).

Independentemente, a maioria dos artigos facilita o discernimento notificando os leitores:

Acrescente ao :

# Esse alias faz o ls colorizar a listagem
alias ls='ls --color=auto'

Acrescentar, adicionar, criar, editar

Ao ser solicitado a acrescentar a, adicionar a, criar ou editar um ou mais arquivos, está implícito que você deve usar um dos seguintes métodos.

Para criar ou modificar arquivos multilinha, sugere-se usar um editor de texto. Por exemplo, usando o comando nano para editar o arquivo /etc/bash.bashrc:

# nano /etc/bash.bashrc

Para criar ou sobrescrever um arquivo de uma string, pode ser mais simples usar um redirecionamento da saída. O exemplo a seguir cria ou sobrescreve os conteúdos do arquivo com o texto .

# echo meuhostname > /etc/hostname

Redirecionamento de saída também pode ser usado para anexar um texto a um arquivo. O exemplo a seguir acrescenta o texto ao final do arquivo .

# echo "[repo-personalizado]" >> /etc/pacman.conf

Ao ser solicitado a criar diretórios, use o comando mkdir:

# mkdir /mnt/boot

Tornar executável

Após criar um arquivo, se ele é feito para ser executado com um script (seja manualmente ou chamado por um outro programa), ele precisa ser definido como executável, por exemplo com:

$ chmod +x script

Veja chmod. Alguns aplicativos como gerenciador de arquivos podem fornecer interfaces gráficas para fazer o mesmo.

Source

Alguns aplicativos, notavelmente shells de linha de comando, usam scripts para suas configurações: após modificá-los, eles devem ser carregados, usando o source, de forma que as alterações sejam aplicadas. No caso do bash, por exemplo, isso é feito executando (você também pode substituir por ):

$ source ~/.bashrc

Quando o wiki sugere modificar tal script de configuração, ele não vai lembrar-lhe explicitamente de carregar o arquivo, e apenas em alguns casos ele vai apontar essa seção com um link de lembrete.

Instalação de pacotes

Quando um artigo o convida para instalar alguns pacotes na forma convenciona, ele não vai indicar as instruções detalhadas para fazê-lo; ele vai simplesmente mencionar os nomes dos pacotes a serem instalados.

As subseções abaixo fornecem uma visão geral dos procedimentos genéricos de instalação dependendo do tipo de pacote.

Pacotes oficiais

Para pacotes dos repositórios oficiais, você precisará ler alguma coisa como:

Instale o pacote foobar.

Isso significa que você tem que executar:

# pacman -S foobar

O artigo do pacman contém explicações detalhadas para lidar com gerenciamento de pacote na proficiência do Arch Linux.

Arch User Repository

Para pacotes do Arch User Repository (AUR) você lerá alguma coisa como:

Instale o pacote foobar^AUR.

Isso significa que, em geral, você tem que seguir o link foobar^AUR, baixar o pacote com o PKGBUILD, extraí-lo, verificar o conteúdo e, finalmente, executar na mesma pasta:

$ makepkg -si

O artigo do Arch User Repository contém todas as explicações detalhadas e melhores práticas para lidar com pacotes do AUR.

Controle de unidades do systemd

Quando um artigo o convida para start (iniciar), enable (habilitar), stop (parar) ou restart (reiniciar) algumas unidades de systemd (ex.: um serviço), ele não indicará as instruções detalhadas para fazê-lo; em vez disso, você lerá, em páginas em inglês, alguma coisa como:

Start .

Isso significa que você tem que executar:

# systemctl start exemplo.service

O link start (iniciar) o levará para o artigo do systemd, que contém todas as explicações detalhadas para lidar com unidades do systemd corretamente no Arch Linux.

Nota:

• Os links start, enable, stop, restart... são redirecionamentos para seções específicas, que pode funcionar apenas se o JavaScript estiver habilitado.
• Em páginas traduzidas para português, você verá links inicie, habilite, pare, reinicie no lugar dos informados acima, o que o levará para systemd (Português).

Configuração do sistema versus específica do usuário

É importante se lembrar que há dois tipos diferentes de configurações em um sistema GNU/Linux. A configuração do sistema afeta todos os usuários. Já que as configurações dos sistemas geralmente estão localizados no diretório /etc, privilégios de root são exigidos para alterá-los. Por exemplo, para aplicar uma configuração de Bash que afeta todos os usuários, /etc/bash.bashrc deve ser modificado.

Configuração específico do usuário afeta apenas um único usuário. Dotfiles, que são arquivos iniciados com ponto, são usados para configuração específica do usuário. Por exemplo, o arquivo é o arquivo de configuração específica de usuário. A ideia é que cada usuário pode definir suas próprias configurações, tal como aliases, funções e outros recursos interativos como o prompt, sem afetar as preferências de outros usuários.

Arquivos de shell comum

Bash e outros shells compatíveis com Bourne, tal como Zsh, também carregam arquivos dependendo do shell ser um shell de login ou um shell interativo. Veja Bash#Configuration files e Zsh#Startup/Shutdown files para detalhes.

Pseudo-variáveis no exemplos de código

Alguns blocos de código podem conter as chamadas pseudo-variáveis, que, como o nome sugere, não são realmente variáveis usadas no código. Em vez disso, elas são substitutos genéricos e têm que ser substituídos manualmente com itens de configuração do sistema antes do código poder ser executado ou analisado. Shells comuns como bash e zsh fornecem completação por tab para autocompletar parâmetros para comandos comuns, tal como systemctl.

Nos artigos que estão em conformidade com Help:Estilo/Formatação e pontuação, pseudo-variáveis são formatadas em itálico. Por exemplo:

• Enable (equivalente a Habilite) o para a interface de rede identificada a partir da saída do comando .

Neste caso é usado como um substituto pseudo-variável em uma unidade modelo de systemd. Todas as unidades modelo de systemd, identificáveis pelo sinal , exigem um item de configuração do sistema como argumento. Veja Systemd (Português)#Usando units.

• O comando pode ser executado como root para apagar uma partição com parâmetros específicos.

Neste caso, as pseudo-variáveis são usadas para descrever os parâmetros que devem ser substituídos por elas. Detalhes sobre como juntá-las são elaborados na seção Securely wipe disk#Calculate blocks to wipe manually, que fornece o comando.

No caso dos exemplos de arquivos, colar pseudo-variáveis em arquivos de configuração reais pode quebrar os programas que os usam.

Reticências

Na maioria dos casos, as reticências () não são parte do conteúdo do arquivo ou saída de código e, em vez disso, representam texto omitido ou opcional que não é relevante para o assunto discutido.

Por exemplo ou:

/etc/X11/xorg.conf.d/50-synaptics.conf

Section "InputClass"
    ...
    Option      "CircularScrolling"          "on"
    Option      "CircScrollTrigger"          "0"
    ...
EndSection

Esteja ciente de que, em alguns casos, reticências podem ser parte significante da sintaxe do código: usuários atenciosos serão capazes de reconhecer facilmente esses casos pelo contexto.