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.
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 "Don't Repeat Yourself" ("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: foobarAUR
Root, usuário comum ou outro usuário
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.
#
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.Quando os comandos precisam ser executados como um usuário específico, eles serão prefixados pelo nome de usuário entre colchetes, por exemplo:
[postgres]$ initdb -D /var/lib/postgres/data
Isso significa que você deve usar uma ferramenta de elevação de privilégios, por exemplo, com sudo:
$ sudo -u postgres initdb -D /var/lib/postgres/data
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 ~/caminho/para/arquivo
:
# 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 /etc/hostname
com o texto meuhostname
.
# 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 [repo-personalizado]
ao final do arquivo /etc/pacman.conf
.
# 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 source
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 foobarAUR.
Isso significa que, em geral, você tem que seguir o link foobarAUR, 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), etc., alguma unidade 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
exemplo.service
.
Isso significa que você tem que executar:
# systemctl start exemplo.service
Um comando notável que não segue esse padrão exato é daemon-reload, que será chamado sem argumentos.
A seção systemd#Usando units contém uma lista estruturada de ações disponíveis (como start, enable, enable and start, etc.) com seus comandos systemctl correspondentes.
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 ~/.bashrc
é 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.
~/
e $HOME
são atalhos para o diretório home do usuário, geralmente/home/nomedeusuário/
.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
dhcpcd@nome_interface.service
para a interface de rede identificada a partir da saída do comandoip link
.
Neste caso nome_interface
é 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#Usando units.
- O comando
dd if=origem_dados of=/dev/sdX bs=tamanho_setor count=número_setor seek=setor_início_partições
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 HOOKS="... encrypt ... filesystems ..."
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.