Módulo 1: A linguagem

Desta vez, nós precisaremos descobrir quais são os recursos que o shell oferece para que possamos escrever scripts capazes de lidar com tomadas de decisão, mas não é só isso! Nesta aula, nós também aprenderemos:

• Como passar argumentos para os nossos scripts e como acessá-los.
• Como determinar se temos dados na entrada padrão.
• Como fazer a leitura de uma ou mais linhas de texto na entrada padrão.
• Como definir a execução condicional de comandos.

Como os nossos problemas estão começando a ficar mais complexos, esta é uma boa hora para aprendermos a resolvê-los de uma forma que, além de nos levar às soluções, também nos ajude a transformar cada desafio, presente ou futuro, em oportunidades para a produção e consolidação de conhecimento.

Dominando o método para solucionar o problema de atravessar ruas, é possível que alguém tenha desenvolvido estratégias que funcionam muito bem para alguns tipos de situações particulares. O finado professor de matemática Augusto Morgado chamava essas abordagens de "truques": boas ideias que resolvem casos particulares de um problema.

No aprendizado do shell (e de quase todas as linguagens de programação), não é diferente. Nós somos frequentemente tentados a confundir o domínio de certos truques com algum tipo de superioridade de conhecimento e domínio da área. Nós temos até um nome para as pessoas que conquistam nossas admirações (e as nossas curtidas) com esse tipo de expediente: são os famosos ninjas das mais diversas áreas.

Contudo, como dizia o professor Morgado:

Truque é uma boa ideia que resolve um problema; método é uma boa ideia que resolve vários problemas.

Isso quer dizer que, dominado o método, não há problema algum em nos divertirmos experimentando e descobrindo soluções mágicas para casos particulares do problema que o método soluciona: o que não devemos fazer, é super valorizar os truques ou priorizá-los enquanto ainda estamos aprendendo. Um exemplo disso, é o uso das aspas na expansão de parâmetros. Quantas vezes nós já não ouvimos especialistas em shell afirmando que: por garantia, sempre devemos usar aspas quando expandirmos uma variável?

Este é um mito tão difundido, que até o linter (programa que verifica códigos) do shell, o shellckeck, tem um alerta específico para isso, o SC2086:

Double quote to prevent globbing and word splitting.

Em tradução livre:

De fato, a ausência de aspas pode ter as consequências advertidas, mas nem sempre isso é relevante ou é uma coisa ruim. Observe este exemplo:

:~$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.9.9-1 (2024-07-13)

O que nós temos aqui, é a versão do kernel em uso no meu sistema. Nesta linha, composta por várias palavras, a última é a data da compilação feita pelos mantenedores do Debian. Se eu quisesse obter especificamente essa informação (a data da compilação), e conhecesse alguns utilitários da base do sistema, eu poderia fazer algo assim:

:~$ uname -v | rev | cut -d' ' -f1 | rev
(2024-07-13)

Outra possibilidade seria:

:~$ uname -v | awk '{print $NF}'
(2024-07-13)

Ou então, apenas com recursos do Bash:

:~$ : $(uname -v); echo $_
(2024-07-13)

Neste último caso, repare que estou expandindo (propositalmente) a substituição de comandos. O motivo é simples e não tem nada de mágico: as palavras da linha expandida serão passadas como argumentos do comando nulo (:) e, em seguida, eu pretendo obter a última palavra com a variável especial _ (underlined), que expande o último argumento do último comando executado. Como você pode ver, minha abordagem funcionou perfeitamente, mas o que aconteceria se eu desse ouvidos aos ninjas:

:~$ : "$(uname -v)"; echo "$_"
#1 SMP PREEMPT_DYNAMIC Debian 6.9.9-1 (2024-07-13)

Como a substituição de comandos está entre aspas, toda a linha foi passada para o comando nulo como um único argumento, e foi isso que $_ expandiu. Além disso, as aspas na expansão do _ poderiam ser importantes, mas não neste caso, porque, uma das coisas que precisamos garantir antes de adotar qualquer abordagem na solução de problemas com o shell, é que nós conhecemos os dados com que estamos trabalhando: e eu tenho certeza de que não há nenhuma potencial expansão de nomes de arquivos e de que é impossível acontecer uma separação de palavras neste caso!

Para quem não conhece o shell, pode parecer que eu recorri a um truque para solucionar o problema, mas isso não é verdade: eu utilizei um método e o meu conhecimento de como o Bash funciona para chegar a essa implementação em código. Seria um truque, se a minha solução se aplicasse a um caso particular do problema "imprimir a última palavra de uma linha expandida utilizando apenas recursos do Bash", mas não, esta é uma solução perfeitamente aplicável a qualquer circunstância do problema. Tanto que eu poderia até formalizá-la com a sintaxe geral:

Expandir a última palavra de uma linha

: EXPANSÂO; echo $_

Sendo assim, o caso particular seria quando a última palavra de EXPANSÃO fosse um curinga (um caractere que expande nomes de arquivos). Nesta situação, as aspas seriam totalmente indiferentes, pois nomes de arquivos seriam expandidos de qualquer forma, e eu teria que procurar outra solução.

Observe:

:~$ var='banana laranja $BASH_VERSION'
:~$ : $var; echo $_
$BASH_VERSION

Mesmo sem aspas, não houve expansão da variável BASH_VERSION, mas seria diferente com uma expansão de nomes de arquivos:

:~$ var='banana laranja *'
:~$ : $var; echo $_
www

Independente das aspas, a última palavra expandida por var será * e, como as expansões de nomes de arquivos são processadas depois das expansões de parâmetros, não importa o que eu faça, elas acontecerão. Já as expansões de parâmetros (como no exemplo anterior), substituições de comandos e as expansões de expressões não são processadas simplesmente porque nenhuma expansão é recursiva, ou seja: expansões não podem ser expandidas em expansões do mesmo tipo.

Do problema de "imprimir a última palavra de uma linha apenas com recursos do Bash" à formulação geral da solução, incluindo as ressalvas e as limitações, não houve mágica nem atalhos: eu tive que recorrer a uma ferramenta que me ajudasse a encontrar uma solução que pudesse ser consolidada como conhecimento – e o nome dessa ferramenta é método!

Se, em algum sentido, métodos são ferramentas para produzir conhecimento, é justo esperar que um método aplicado à solução de problemas computacionais não se limite a “resolver” esses problemas: o método que nos interessa tem que ser capaz de nos levar além do resultado para que seja possível transformar problemas em conhecimento!

Inspirados no método em quatro etapas do matemático e professor húngaro Georges Pólya, nós elaboramos o método que temos recomendado já há alguns anos. Com ele, a ideia é conduzir a pessoa que está diante de um problema para resolver com o shell (e outras ferramentas disponíveis no sistema) ao longo de passos conscientes e seguros na direção de resultados que possam ser testados e consolidados, tanto como solução, quanto como conhecimento.

Antes de conhecermos o método, porém, é importante enfatizar a importância de um passo anterior, facilmente ignorado, mas que é decisivo para a solução de qualquer problema, seja com que método for:

Sem adotar firmemente essa postura, será muito difícil construir a motivação e o nível de envolvimento, necessários para aguçar os sentidos e o pensamento crítico e levar todo o processo de solução até o fim. Neste ponto, pode ser útil adotar algumas estratégias:

Estabelecer um “limite de competência”

Tudo bem recorrer imediatamente a manuais e buscas na web, mas as perguntas em fóruns e grupos de ajuda só devem ser feitas após um tempo mínimo limite que você mesmo estabelecer.

Divida o problema em problemas menores

Boa parte dos problemas não será resolvida apenas com uma técnica ou com apenas uma ferramenta – então, comece tentando identificar o que talvez você já conheça e vá montando o quebra-cabeça aos poucos.

Fortaleça a sua base conceitual

Entender como as coisas funcionam e por que funcionam não é perda de tempo – boa parte dos problemas podem ser resolvidos com a simples observação de como os conceitos e princípios básicos serão postos em ação.

Cada problema é um novo problema

Por mais paradoxal que pareça, olhar cada problema com espanto, como se fosse algo absolutamente novo, tem o poder de despertar todo o nosso arsenal de soluções anteriores, ao passo que, pressupondo tratar-se de algo já visto e aprendido, quase sempre nos leva belos tropeços e escorregões.

Partindo do pressuposto de que, no mundo real, os problemas nunca vêm com enunciados, nosso primeiro papel será analisar o problema até que ele possa ser descrito na forma de um enunciado que nós mesmos elaboramos. Aqui, vale qualquer técnica pessoal que nos leve a um bom enunciado, mas pode ser uma boa ideia verificar se ele poderia ser compreendido por uma criança de 5 anos.

Na modelagem, nós tentamos descrever o enunciado na forma de uma lista de procedimentos que, eventualmente, será um modelo da própria solução. Por exemplo, imagine que o problema seja: “faça um misto-quente”. Por mais simples que este enunciado pareça, ele envolve questões bastante complexas! Veja, foi a familiaridade com o ato de fazer mistos-quentes que ocultou a complexidade, mas ela ainda está lá. Então, quando alguém nos pede um misto-quente, nós já sabemos que:

• Teremos que pegar duas fatias de pão de forma;
• Passar manteiga numa das faces de cada uma delas;
• Pegar duas fatias de presunto e duas fatias de queijo;
• Colocar as fatias entre as faces amanteigadas do pão de forma;
• Ligar a boca do fogão onde o sanduíche será feito;
• Colocar o sanduíche frio numa chapa ou numa sanduicheira;
• Controlar o aquecimento da chapa para que o sanduíche não queime;
• Retirar o sanduíche da chapa quando estiver pronto.

Eu poderia ser até mais detalhado, mas acho que você entendeu a ideia. O que eu preciso que você perceba, é que, no conjunto, o meu procedimento equivale diretamente ao enunciado: “faça um misto-quente” – ou seja, dizer uma coisa ou a outra teria o mesmo efeito. Como tanto o enunciado quanto o procedimento apontam para a realização do fato (ter um misto-quente), nós podemos dizer que ambos descrevem a solução, só que, no caso do enunciado, a solução está na forma de um problema, enquanto o procedimento é um modelo da solução.

Antes de passarmos à próxima etapa, a modelagem tem uma regra importante: jamais se pergunte como os processos poderão ser realizados! A ideia aqui é determinar o que deve ser feito: o “como” é assunto para a implementação.

É nesta etapa que nós descobrimos o que poderá ser escrito para realizar cada um dos procedimentos descritos na etapa da modelagem. Sendo assim, nada melhor do que tentarmos aplicar o que já vimos do método ao nosso problema: