Embelezando o shell do seu Raspberry Pi / Banana Pi / Orange Pi / Odroid / etc

Embelezando o shell do seu Raspberry Pi / Banana Pi / Orange Pi / Odroid / etc

Vamos começar esse post polemizando. O Linux é um kernel, não é um sistema operacional. Um sistema operacional é composto por um kernel, um interpretador de comandos e um sistema de arquivos.

Agora alguns já estão babando sangue, mas vamos lá; o sistema operacional baseado em Linux se chama GNU/Linux. Isso porque o kernel é o Linux e as ferramentas envoltas são todas GNU.
Em relação ao GNU, só por curiosidade, trata-se de um acrônimo recursivo que significa “GNU is Not Unix”. Isso significa que os sistemas operacionais baseados em Linux são POSIX (Portable Standard UNIX), mas não são UNIX propriamente dito, porque para isso algumas licenças haveriam de ser pagas.
Porque toda essa enrolação pra falar de personalização do shell? – Eu pergunto, eu respondo.
Tudo que você ver no sistema que for orientado a mouse, não passa de uma máscara para interfacear com o usuário. Isto é, tudo que o usuário não souber fazer manualmente, haverá de se contentar com os recursos oferecidos pelas aplicações gráficas. Isso é ruim? Bem…
…no Linux, 99% das aplicações são front-ends. Isto é, facilitadores para usuários orientados a mouse. Porém, nem todos os recursos da ferramenta estão disponíveis na maioria dessas aplicações. Outra desvantagem é a verbosidade que é sucumbida pela interface. Vejo usuários de ubuntu (e lá vem polêmica) que não conseguem rodar um programa clicando nele pela interface gráfica. Claro que isso seria o normal, mas se o usuário soubesse chamar o aplicativo pelo shell, teria informações sendo exibidas na saida padrão. Hum? Não sabe o que é a saída padrão?
No sistema existem 3 tipos de fluxo;
STDIN – o que vem do usuário para o sistema.
STDOUT – O que sai do sistema para o console.
STDERR – O que sai do sistema para o console.
Primeiro, console é terminal, o terminal TTY ou PTY que te dá acesso ao interpretador de comandos. Hum? Não sabe o que é interpretador de comandos?
O sistema operacional tem alguns níveis de pré-configuração antes de se tornar disponível. Primeiramente ao iniciar um sistema operacional, carrega-se o kernel. O kernel é o cerne do sistema, que contém as instruções necessárias para fazer a interface entre a máquina e o restante do sistema. Após a carga do kernel, em sua segunda fase (exceto seja um kernel estático) ele carrega módulos, ou popularmente, drivers. Esses drivers necessitam de um outro nível de comunicação interpretada e é aí que entra o interpretador de comandos, ou, shell. Ou console.
Mas porque o kernel precisa do shell? – Simples – ele está executando dados que ficam no user space. Hum? Não sabe o que é user space?
O sistema operacional (não em todas as arquiteturas) tem seu kernel trabalhando em modo protegido. Isto é, há uma área de memória reservada que não pode ser invadida ou acessada por outras aplicações. Desse modo, tudo que é bit pode travar, mas o kernel continuará rodando. Esse é chamado de ‘kernel space’.
O ‘user space’ é a área de sistema onde o usuário pinta e borda, dentro das restrições impostas pela hierarquia do sistema de arquivos. Você achou que o sistema de arquivos era só um tapete para os arquivos, né?

Como você pode ver, existe todo um universo atrás do seu papel de parede, mas você provavelmente está perdendo porque as comodidades que foram colocadas sobre o sistema operacional  afastaram os usuários do background. Com o propósito de atraí-lo para a linha de comando, decidi fazer esse breve post para mostrar que um shell também pode ser legal e diferente. E tem sim coisa pra personalizar! Mas antes de seguirmos, vou tirar aquela farpa dos seus olhos; no parágrafo lá em cima onde falei que STDERR e STDOUT saem para o console do sistema, é verdade, mas eles não estão saindo no mesmo lugar, apesar de você estar vendo. Isto é, STROUT é a saida 1 e STDERR é a saída 2. Se você quiser ver as mensagens da saída padrão ignorando mensagens de erro você pode redirecionar STDERR para o limbo. O limbo no Linux tem um nome, é um dispositivo de sistema e acessível por todos. Chama-se ‘null’ e obviamente está em /dev. Do msmo modo, você pode ler só a saída de erro no shell. Vamos iniciar a brincadeira com o shell por ai. Tudo vai para a saida padrão, portanto:

O echo é um programa usado para exibir mensagens. Quando você o executa seguido de um parâmetro, seu parâmetro é exibido na saida padrão. Deixe-me apresentar-lhe o limbo:
Aqui já coloquei 2 modos; a saida padrão e a saida padrão explicita. Veja que direcionei stdout para o comando (<&1) e o resultado disso para o dispositivo /dev/null (>/dev/null). Isto é, o resultado do comando foi descartado; enviado para o olho do buraco negro. Na primeira linha, sem maiores frescuras, apontei diretamente para /dev/null.
Agora vamos manipular a saida de erro.

Aqui temos 3 condições interessantes. A primeira, executando o comando echo apontando stderr (2) para o dispositivo /dev/null. Mas a mensagem saiu no console. Porque isso? – Eu pergunto, eu respondo.
O comando executou uma operação normal, não houve erros, portanto o resultado foi para STDOUT. O que foi redirecionado para o limbo foi STDERR. Não aconteceu erro nenhum, portanto nada foi pra lugar nenhum.
Na segunda linha direcionei a saída de erro para a entrada padrão, e então ambos foram apontados para o dispositivo /dev/null. Nesse caso nada foi exibido na tela porque STDOUT foi apontando para /dev/null. A única diferença na segunda e terceira linha é que a saída de erro foi direcionada para a saida padrão, mas em nenhuma hipótese haveria mensagem de STDERR.

 

A crase cercando um comando significa que queremos que o comando echo exiba o resultado do que foi executado dentro de crase. Só que esse comando dá um erro, então o echo retorna aquele espaço em branco porque não teve resultado. Na linha seguinte, a saida padrão é redirecionada para /dev/null e apenas a resposta do comando cat é exibida em STDERR.

Agora vamos iniciar a personalização do shell e você verá que tudo que falei a respeito de STDERR, STDOUT e STDIN só serviu pra consumir seu tempo com a leitura.

Personalizando a PS1
Vou usar agora a conexão com o Raspberry Pi para personalizar a PS1 porque ela é terrivelmente feia. Alias, o shell do Raspberry Pi é todo desconfigurado.

Essa é a conexão padrão do SSH. Ela está assim:

Vamos só dar um tapinha:

Isso resulta em algo assim:

§dobitaobyte.com.br:([email protected])#/usr/src§

Agora, como saber as cores  e definiçoes? Bem, primeiro vamos ver como montar esse comando:

 

Desse modo, você vai criando seu set de instruções para cada letra, se quiser. Quando finalizar, o último set de instruções necessário:

 

 

Dica master: Cada vez que você digitar a PS1, coloque a seta pra cima e depois para baixo. Se tiver algum erro, ficará resquicios da PS1 no console. Corrija o comando até que tudo fique bem. Além disso, você pode usar alguns expansores como o host (h), path (w), usuario (u) e alguma coisa mais que não lembro e estou com preguiça de pesquisar.
Agora, como saber as cores aplicáveis para o console? Bem, as cores podem ser combinadas, mas aí a PS1 vai ficar mais complexa e você pode se frustar ao tentar compô-la. Por conta disso, fiz a PS1 com o mais simples dos casos. Para saber as cores disponíveis, vamos configurar agora cores para extensões de arquivos e tudo ficará claro. Mas primeiro, se sua PS1 lhe agradou, coloque-a em seu .bashrc, substituindo a pré-existente.

Mudando cores de arquivos com o dircolors

 

Você pode mudar absolutamente tudo, mas se o diretório deixar de ser azul e executáveis deixarem de ser verde, qualquer pessoa acostumada com o bash ficará perdida e não poderá usar dircolors para se guiar. Antigamente quando o shell não tinha cores, as referências eram simbolos que seguiam os nomes de arquivos. Para ver como era, faça o seguinte:


Como você poderá notar, os arquivos recebiam por padrão um sufixo que representava seu tipo:

 

Adicionalmente, arquivos ocultos podem ser listados com o comando ‘ls -a’. Arquivos ocultos iniciam com ‘.’, que serve como identificador, mas não é um identificador. Na verdade, o ponto é a flag para o sistema de arquivos ocultar o arquivo, exceto sua exibição seja explicitamente solicitada.
Para mudar a cor, prepare primeiramente um arquivo utilizando a própria base nativa do sistema para facilitar:
Isso gerará um arquivo contendo todos os padrões definidos no sistema e uma lista comentada das cores possíveis e todas as instruções disponíveis. A partir desse arquivo você poderá personalizar sua PS1!
Modifique ou adicione suas próprias extensões (preferencialmente, a segunda opção) e depois modifique (ou adicione) a chamada para esse arquivo em ~/.bashrc ou /etc/profile. Uma linha assim deverá ser inserida:
eval dircolors /etc/DIR_COLORS

Tem macros também nesse arquivo, leia-o para aprender mais.Apelido para comando. Aliás, alias.

Essa é mais uma belezinha que deve ser usado com moderação, senão pode te levar à loucura.
Suponhamos que você sempre manipula arquivos de um pendrive e sempre faz a listagem de um diretório para ver os arquivos. Toda a vez  você digita (hipoteticamente):

 

É um saco. Mas você já fez isso outras vezes, então basta usar Ctrl+R e iniciar a digitação do comando. Automaticamente a linha toda se completará. Mas supondo que você esteja com a tecla Ctrl indisponível porque sua filha de 3 anos mexeu no seu notebook e quebrou a única tecla Ctrl que tinha porque o fabricante achou por bem reduzir o tamanho do teclado removendo o shift e o Ctrl direito.

Nesse caso, você pode criar um script shell. Um script só pra você listar um diretório; é como matar barata com o martelo do Thor. Nesse caso, a solução correta é um alias.

 

Esse comando pode ser colocado no ~/.bashrc. Assim, toda a vez que você se conectar ao Raspberry para listar os arquivos do pendrive, bastará digitar:

 

Pequena embelezada com ASCII art
 
Essa é muito bico. Existem diversos geradores de ASCII art online. Vou recomendar um, mas esteja a vontade para ir a qualquer outro que desejar. Nesse site que recomendo tem diversos modelos diferentes, escolhi esse que segue após o link:
Depois de gerado, você clica em “copiar texto”, então vai ao shell do Raspberry, edita o arquivo ~/.bashrc e após a última linha, cola esse texto. Aí basta fazer um echo pro terminal, desse modo:

 

Djames Suhanko gosta de suco de abacaxi com couve, como sua mãe lhe ensinou. Dono de uma cabeleira estonteante, Djames se desdobra em mil entre suas caçadas de churruminos, seu treinamento de equilibrio de agulha na ponta do nariz e seu site:
Finais de semana ele gosta de tocar violão, clarinete e prender palito de dente na campanhia dos vizinhos.
Visite seu site e também Cadastre-se em seu canal do Youtube.

Related Post