103.1 Lição 2

Então, como identificamos os valores atuais para cada uma de nossas variáveis de ambiente? Uma maneira de fazer isso é por meio do comando env:

Aparecerão muitos resultados — bem mais do que os incluídos no trecho acima. Mas, por enquanto, observe a entrada PATH, que contém os diretórios nos quais seu shell (e outros aplicativos) procura por outros programas sem a necessidade de especificar um caminho completo. Neste caso, seria possível executar um programa binário que reside, digamos, em /usr/local/bin de dentro do seu diretório pessoal, e ele seria executado como se o arquivo fosse local.

Vamos mudar de assunto um pouquinho. O comando echo exibe na tela o que você mandar. Acredite ou não, haverá diversas ocasiões em que será muito útil fazer echo literalmente repetir algo.

Mas echo tem outras cartas na manga. Quando você o alimenta com o nome de uma variável de ambiente — e informa que se trata de uma variável, com o prefixo $ — ao invés de apenas exibir o nome da variável, o shell irá expandi-lo, informando o valor. Não tem certeza se o seu diretório favorito está atualmente em PATH? Você pode verificar rapidamente com o echo:

Você pode adicionar suas próprias variáveis personalizadas ao seu ambiente. A maneira mais simples é usar o caractere =. A string à esquerda será o nome da nova variável e a string à direita, seu valor. Depois, alimente echo com o nome da variável para confirmar se funcionou:

Mas será que funcionou mesmo? Digite bash no terminal para abrir um novo shell. Ele terá exatamente a mesma aparência daquele que acabamos de usar, mas na verdade é um filho do original (que chamamos de pai). Agora, dentro desse novo shell filho, tente fazer com que o echo opere sua mágica da mesma maneira de antes. Nada. O que aconteceu?

Uma variável criada da maneira como acabamos de fazer só estará disponível localmente — dentro daquela sessão de shell imediata. Se você iniciar um novo shell — ou fechar a sessão usando exit — a variável não irá junto. Aqui, se você digitar exit, será levado de volta ao shell pai original que, no momento, é onde queremos estar. Execute echo $myvar mais uma vez se quiser apenas confirmar que a variável ainda é válida. Depois digite export myvar para passar a variável para quaisquer shells filhos que possam ser abertos posteriormente. Experimente: digite bash para abrir um novo shell e em seguida use echo:

Tudo isso pode parecer bobagem quando estamos criando shells sem um propósito real. Mas é importantíssimo entender como as variáveis do shell são propagadas pelo sistema para quando você começar a escrever scripts sérios.

Quer saber como limpar todas as variáveis efêmeras que você criou? Uma maneira de fazer isso é simplesmente fechar o shell pai — ou reiniciar o computador. Mas existem jeitos mais simples. Como, por exemplo, unset. Basta digitar unset (sem o $) para matar a variável. Comprove com echo.

Se um comando unset existe, pode apostar que também há um comando set complementar. A execução de set por si só exibirá um monte de saídas, mas nada muito diferente de env. Observe a primeira linha da saída obtida ao filtrarmos por PATH:

Qual a diferença entre set e env? Para nossos propósitos, a principal delas é que set exibe todas as variáveis e funções. Para ilustrar isso, vamos criar uma nova variável chamada mynewvar e em seguida confirmar se ela está lá:

Se rodarmos env usando grep para filtrar pela string mynewvar, nenhuma saída será exibida. Mas se rodarmos set da mesma maneira, veremos nossa variável local.

Este é um bom momento para apresentar o problema dos caracteres especiais. Os caracteres alfanuméricos (a-z e 0-9) normalmente são lidos literalmente pelo Bash. Para criar um novo arquivo chamado myfile, bastaria digitar touch seguido de myfile e o Bash saberia o que fazer. Mas se quisermos incluir um caractere especial no nome do arquivo, teríamos um pouco mais de trabalho.

Para ilustrar esse fato, digitaremos touch e em seguida o título: my big file. O problema é que existem dois espaços entre as palavras que o Bash interpretará. Embora, tecnicamente, espaços não sejam “caracteres”, é assim que eles se comportam, já que o Bash não os lerá literalmente. Se você listar o conteúdo do diretório atual, em vez de um arquivo chamado my big file, verá três arquivos chamados, respectivamente, my, big, e file. Isso porque o Bash pensou que você queria criar vários arquivos cujos nomes estavam sendo dados em uma lista:

Os espaços serão interpretados da mesma forma se você excluir (rm) os três arquivos com um só comando:

Agora, vamos fazer do jeito certo. Digite touch e as três partes do seu nome de arquivo, mas desta vez coloque o nome entre aspas. Desta vez, funciona. Ao listar o conteúdo do diretório, veremos um único arquivo com o nome correto.

Existem outras maneiras de obter o mesmo efeito. As aspas simples, por exemplo, funcionam da mesma forma que as aspas duplas (note que as aspas simples preservam o valor literal de todos os caracteres, ao passo que as aspas duplas preservam todos os caracteres exceto $, `, \ e, em certos casos, !.)

Podemos incluir uma barra invertida antes de cada caractere especial para “escapar” dessa característica e fazer com que o Bash o leia literalmente.