Desconfiando desde o principio

Shell scripts seguem a sintaxe do interpretador de comandos a que são direcionados.

Assim, surgem alguns termos que podem ser estranhos ao nosso vocabulário.

- Sintaxe e interpretador de comandos?

Com pretensões heróicas a parte, este artigo pode te salvar de efeitos de obscurantismo tecnológico.

Pois então, iniciaremos mais uma missão possível.

Cursinhu di purtogéys

O que é sintaxe?

O significado do termo sintaxe quando referente as linguagens de programação é plenamente equiparável ao sentido dado ao mesmo em relação a comunicação humana. Você, se não sabia, desconfiava, e muito disso.

Analogamente, assim como cada idioma humano escrito tem seu conjunto de regras fixas chamado costumeiramente de gramática, cada linguagem de programação tem as suas as quais chamamos de sintaxe.

Uma metamorfose ambulante chamada shell

Se um nome diz muito sobre qualquer coisa, a limitação dos recursos que uma linguagem de programação utiliza/manipula e/ou é destinada, ou seja, os objetivos para qual foi projetada (core de trabalho), são pontos altamente consideráveis.

Por exemplo, citaremos o nome da linguagem side-server, PHP, cuja a sigla originalmente significava Personal Home Page, e que hoje é um acrônimo recursivo para PHP: Hypertext Preprocessor devido à evolução de seu core.

No caso de uma shell, a sintaxe usada por um interpretador de comandos, que é o tradutor entre o sistema operacional e o usuário, é (em minha opinião), muito levada em consideração como caracterizador do mesmo.

Expandindo a explicação sobre este conceito digo que a sintaxe, é um determinante dos tipos de shell (interpretador de comandos) e um dos, senão, o principal fator usado para as denominar. E que a quantidade de recebimento ou não de herança de sintaxe e core entre elas e outras linguagens que originalmente não tenham sido criadas para serem utilizadas em shells scripts é também muito considerada.

Para ficar mais clara minha afirmação, entre os muitos tipos de shell existentes serão citados neste texto de maneira resumida, mas buscando a manutenção de foco e procurando seguir uma sequência cronológica motivada pela importância histórica para os sistemas GNU/Linux atuais, apenas alguns tipos. Ei-los;

Bourne shell (.sh)

Desenvolvido em 1977 por Stephen Bourne dos laboratórios AT&T. Por muito tempo foi o shell padrão de usuários em sistemas Unix.

Cshell ( .csh)

Como seu nome sugere, esta shell usa um modelo de sintaxe baseado na linguagem C. Talvez por ignorar o legado de facilidades didáticas do .sh está cada vez mais fora de uso no GNU/Linux.

Korn shell (.ksh)

Baseado no código do Cshell, foi o primeiro shell a introduzir recursos avançados entre outras versatilidades.

Bash (Bourne again shell - .sh)

Actualmente é o mais utilizado interpretador de comandos em sistemas GNU/Linux. Desenvolvido para o projeto GNU é o padrão de várias distribuições Linux. É compatível com o Bourne shell além de incorporar os melhores recursos do Cshell e do Korn Shell e adicionar outros consecutivamente a cada nova versão.

Devido as suas qualidades (herança de recursos manipuláveis e de sintaxe e principalmente amplo uso no GNU/Linux) a bash será a gramática (leia: tipo de shell e portanto a sintaxe) a ser estudada por nós no decorrer de nossos artigos sobre shell scripts.

Além disso, shells scripts, especialmente os escritos para o interpretador bash, possuem um core de objetivo geral limitado apenas pelos recursos que o sistema oferece (comandos) e estes mesmos sujeitos a ampliação se aliados a criatividade e conhecimento do programador pela existência da possibilidade de adicionar novos recursos ao mesmo (novos comandos), claro, paridas de acordo com o surgimento de novas necessidades passiveis de solução. Logo a potencialidade evolutiva de seus super poderes (tanto do sistema quanto do pretenso programador) são óbvios.

Além destas vantagens e outras que tenho por presunção posterior explicar em outros artigos (se Deus me permitir), shells scripts, oferecerem eficiência devastadora também em prototipagem.

Santa prototipagem Tux-man!

Sim… Jovem e muito prodigioso jedi, prototipagem é derivada da palavra… protótipo.

E quando referido a programação, prototipagem, é um ante projeto confeccionado para testar os recursos que um sistema originalmente oferece além da redução das incertezas sobre as funcionalidades do mesmo.

Essencialmente (e desprezando muitas fazes de desenvolvimento) pense comparativamente que esta idéia como as fases de relacionamento íntimo chamadas de namoro e noivado como ensaios do objetivo casamento (é... eu também senti muitos calafrios!). Se tudo correr bem casamos. Se surgirem dúvidas ou desastres tentamos consertar a situação ou abandonamos a missão, mas, curiosamente nunca desistimos desta guerra e procuramos outros, digamos, caminhos...

Porém nosso arsenal está mais poderoso agora devido a experiências anteriores e portanto não cometemos os mesmos erros graças as experiências adquiridas… Embora “na prática a teoria seja outra”, quanto a relacionamentos humanos neste nível de intimidade.

Logo, se um código foi, total ou parcialmente, prototipado em shell script, tem muitas chances de ter seus objetivos alcançados quando for traduzido para outra linguagem, além de herdar a portabilidade do shell o que já soluciona muitos problemas de compatibilidades nas dependências de instalação quando o mesmo for portado fora do ambiente de onde originalmente foi depurado. O que pode ser um auxilio na concepção de softwares.

O poder da inteligência e a falta que ela pode fazer

Claro que o alto poder sobre o sistema o qual citamos anteriormente pode gerar falhas de segurança e proteção a integridade do mesmo e por isso, nunca devem ser desprezados, lógico a menos que se tenha total certeza das consequências ao utilizá-lo.

Logo dedicação ao estudo sobre o tema é essencial a sobrevivência e consequente evolução posterior. Tenha sempre em mente que o maior inimigo de um sistema computacional é um usuário mal informado e não o mal intencionado, ou seja, pode ser o que está entre a cadeira e o teclado neste momento.

Como exemplo de mal uso de recursos de um sistema cito um caso pessoal parido por preguiça mental e fatores de mal funcionamento orgânico provocado “sem-vergonhosamente” por grande ingestão de álcool etílico - vulgarmente conhecida como ressaca - a qual me fez executar "acidentalmente" o comando proibido da morte (# rm -rf /*, por favor não tentem fazer isso em casa cri-antas) presenteando-me com um sistema literalmente ” limpíssimo e leve” como a insustentável idiotice do meu ser e por isso, nada funcional. Um exemplo do que eu chamo de etílica leso auto eutanásia antológica (leia - suicídio por uso da lógica de anta etilicamente lesada).

É… Mais um enorme monte de estrume para adubar minha tosca existência no universo de T.I. Mas graças ao “papai do shell” que cuida muito bem de seus filhos, eu tinha um sistema de backup eficiente e não por coincidência escrito em shell script que tirou nota alta em seu teste de prototipagem compulsória.

Cara, cadê a tal da prototipagem?

Calma, Neo. Irei apenas lhe mostrar a porta, mas quem decide atravessá-la será você.

Então observe um minúsculo porém eficaz exemplo que usa outras linguagens além do shell script.

Neste exemplo, temos uma consulta em um banco de dados MySQL diretamente na bash sem que fiquemos permanentemente conectados a CLI(Client Line Interface), onde, usamos:

    mysql\
     -u 'nome_do_usuario_do banco_de_dados'\
     -p 'senha'\
     -d 'base_de_dados'\ 
     -e 'SELECT * FROM foo_tabela;';

Isso gera um resultado como se você tivesse acessado diretamente o SGBD MySQL através da sua shell (CLI - Client Line Interface) e depois se conectado a base de dados para logo depois de executar a query sair imediatamente mostrando o resultado da consulta que pode ser colocado dentro de um Shell Script e seu resultado, caso você queira, guardado dentro de uma variável. Como no exemplo abaixo:

Para utilizar a função acima em um shell script externo basta linka-lo. Como? Digamos que você possui essa consulta e outras que você necessita usar periodicamente. Basta salva-las na forma de funções como no exemplo anterior linka-las e chama-las em um script externo a função. Exemplo:

Deu certo! Então, "bereza mulêcada"!!!

Agora eu sei que esse trecho dará muito certo também em outra linguagem como a C, já que ele foi prototipado em Shell Script.

Shell Script + C language for all

Percebeu como o exemplo anterior é potencialmente perigoso? O shell script é uma linguagem interpretada e portanto os dados da conexão com o BD ficam expostos em um arquivo texto, facilitando a ação de crackers, isso aconteceria se não existisse o controle através da permissão de arquivos um assunto a ser debatido futuramente... Espero!

Uma dica diferente de compilar um script sem o uso do pacote/programa shc (shell script compiler, que é o mais indicado para tal tarefa), que também evita em alguns casos “espertinhos” que tem acesso a conta de root e modificam o código de um shell script, talvez, só para zoar com você, pode ser o uso da função system da linguagem C que chama os comandos que estão no path do sistema.

Para compilá-lo, use o dificílimo comando dentro da pasta onde esta o código fonte:

$ gcc ./nome_do_codigo_fonte.c -o nome_do_executavel

E para executar seu programinha, use a linha seguir dentro do diretório onde foi gerado o executável.

$ ./nome_do_executavel

E seja mais um GNU/Linuxer feliz!!

Mais informações

Sobre como tornar mais seguro o programinha em C leia os comentários deixados em:

http://www.vivaolinux.com.br/artigo/Introduzindo-um-pouco-mais-a-fundo-o-shell-script-(revisado)/

Creative Commons