LINUX USER

Papo de Botequim

Papo de Botequim
Voc no agenta mais aquele seu amigo usurio de Linux enchendo o seu saco com aquela histria de que o sistema fantstico e o Shell uma ferramenta maravilhosa? A partir desta edio vai ficar mais fcil entender o porqu deste entusiasmo...
porque, em ingl s, Shell significa concha, carapa a, isto , fica entre o usu rio e o sistema operacional, de forma que tudo que interage com o sistema operacional, tem que passar pelo seu crivo. Bom j que para chegar ao n cleo do Linux, no seu kernel que o que interessa a todo aplicativo, necess ria a filtragem do Shell, vamos entender como ele funciona de forma a tirar o m ximo proveito das in meras facilidades que ele nos oferece. O Linux, por defini o, um sistema multiusu rio n o podemos nunca nos esquecer disto e para permitir o acesso de determinados usu rios e barrar a entrada de outros, existe um arquivo chamado /etc/passwd, que al m de fornecer dados para esta fun o de le o-de-ch cara do Linux, tamb m prov informaes para o in cio de uma sess o (ou login , para os ntimos) daqueles que passaram por esta primeira barreira. O ltimo campo de seus registros informa ao sistema qual o Shell que a pessoa vai receber ao iniciar sua sess o. Lembra que eu te falei de Shell, fam lia, irm o? Pois , vamos come ar a entender isto: o Shell a conceitua o de concha envolvendo o sistema operacional propriamente dito, o nome gen rico para tratar os filhos desta id ia que, ao longo dos muitos anos de exis-

i logo entreouvido em uma mesa de um botequim, entre um usu rio de Linux e um empurrador de mouse: Quem o Bash? o filho ca ula da fam lia Shell. P cara! Est s a fim de me deixar maluco? Eu tinha uma d vida e voc me deixa com duas! N o, maluco voc j h muito tempo: desde que decidiu usar aquele sistema operacional que voc precisa reiniciar dez vezes por dia e ainda por cima n o tem dom nio nenhum sobre o que esta acontecendo no seu computador. Mas deixa isso pr l , pois vou te explicar o que Shell e os componentes de sua fam lia e ao final da nossa conversa voc dir : Meu Deus do Shell! Porque eu n o optei pelo Linux antes? .

Para voc entender o que e como funciona o Shell, primeiro vou te mostrar como funciona o ambiente em camadas do Linux. D uma olhada no gr fico mostrado na Figura 1. Neste gr fico podemos ver que a camada de hardware a mais profunda e formada pelos componentes f sicos do seu computador. Em torno dela, vem a camada do kernel que o cerne do Linux, seu n cleo, e quem p e o hardware para funcionar, fazendo seu gerenciamento e controle. Os programas e comandos que envolvem o kernel, dele se utilizam para realizar as tarefas para que foram desenvolvidos. Fechando tudo isso vem o Shell, que leva este nome

Desenvolvido por Stephen Bourne do Bell Labs (da AT&T, onde tambm foi desenvolvido o Unix), foi durante muitos anos o Shell padro do sistema operacional Unix. tambm chamado de Standard Shell por ter sido durante vrios anos o nico, e at hoje o mais utilizado. Foi portado para praticamente todos os ambientes Unix e distribuies Linux. Desenvolvido por David Korn, tambm do Bell Labs, um superconjunto do sh, isto , possui todas as facilidades

do sh e a elas agregou muitas outras. A compatibilidade total com o sh vem trazendo muitos usurios e programadores de Shell para este ambiente. Desenvolvido inicialmente por Brian Fox e Chet Ramey, este o Shell do projeto GNU. O nmero de seus adeptos o que mais cresce em todo o mundo, seja por que ele o Shell padro do Linux, seja por sua grande diversidade de comandos, que incorpora inclusive diversos comandos caractersticos do C Shell.

Desenvolvido por Bill Joy, da Universidade de Berkley, o Shell mais utilizado em ambientes BSD. Foi ele quem introduziu o histrico de comandos. A estruturao de seus comandos bem similar da linguagem C. Seu grande pecado foi ignorar a compatibilidade com o sh, partindo por um caminho prprio. Alm destes Shells existem outros, mas irei falar somente sobre os trs primeiros, tratando-os genericamente por Shell e assinalando as especificidades de cada um.

82

Agosto 2004

www.linuxmagazine.com.br

Papo de Botequim

LINUX USER

t ncia do sistema operacional Unix, foram aparecendo. Atualmente existem diversos sabores de Shell (veja Quadro 1 na p gina anterior).

O Shell o primeiro programa que voc ganha ao iniciar sua sess o (se quisermos assassinar a l ngua portuguesa podemos tamb m dizer ao se logar ) no Linux. ele quem vai resolver um monte de coisas de forma a n o onerar o kernel com tarefas repetitivas, poupando-o para tratar assuntos mais nobres. Como cada usu rio possui o seu pr prio Shell interpondo-se entre ele e o Linux, o Shell quem interpreta os comandos digitados e examina as suas sintaxes, passando-os esmiu ados para execu o. pa! Esse neg cio de interpretar comando n o tem nada a ver com interpretador n o, n ? Tem sim: na verdade o Shell um interpretador que traz consigo uma poderosa linguagem com comandos de alto n vel, que permite constru o de loops, de tomadas de decis o e de armazenamento de valores em vari veis, como vou te mostrar. Vou explicar as principais tarefas que o Shell cumpre, na sua ordem de execu o. Preste aten o, porque esta ordem fundamental para o entendimento do resto do nosso bate papo.

Quando digo que o ltimo campo do arquivo /etc/passwd informa ao sistema qual o Shell que o usurio vai usar ao se logar, isto deve ser interpretado ao p-da-letra. Se este campo do seu registro contm o termo prog, ao acessar o sistema o usurio executar o programa prog. Ao trmino da execuo, a sesso do usurio se encerra automaticamente. Imagine quanto se pode incrementar a segurana com este simples artifcio.

redirecionamento, que pode ser de entrada (stdin), de sa da (stdout) ou dos erros (stderr), conforme vou explicar a seguir. Mas antes precisamos falar de...

Neste ponto, o Shell verifica se as eventuais vari veis (par metros come ados por $), encontradas no escopo do comando, est o definidas e as substitui por seus valores atuais.

volvidos (inclusive o pr prio programa), e retorna um erro caso o usu rio que chamou o programa n o esteja autorizado a executar esta tarefa.
$ linux

Neste exemplo o Shell identificou o ls como um programa e o linux como um par metro passado para o programa ls.

Se algum meta-caracter (ou coringa , como *, ? ou []) for encontrado na linha de comando, ele ser substitu do por seus poss veis valores. Supondo que o nico item no seu diret rio corrente cujo nome come a com a letra n seja um diret rio chamado nomegrandeprachuchu, se voc fizer:
$

Se o Shell encontra dois campos separados por um sinal de igual (=) sem espaos em branco entre eles, ele identifica esta seq ncia como uma atribui o.
$

como at aqui quem est manipulando a linha de comando ainda o Shell e o programa cd ainda n o foi executado, o Shell expande o n* para nomegrandeprachuchu (a nica possibilidade v lida) e executa o comando cd com sucesso.

Neste caso, por n o haver espa os em branco (que um dos caracteres reservados), o Shell identificou uma atribui o e colocou 1000 na vari vel valor.

Neste exame o Shell identifica os caracteres especiais (reservados) que t m significado para a interpreta o da linha e logo em seguida verifica se a linha passada um comando ou uma atribui o de valores, que s o os tens que vou descrever a seguir.

Ap s identificar os componentes da linha que voc digitou, o Shell parte para a resolu o de redirecionamentos. O Shell tem incorporado ao seu elenco de habilidades o que chamamos de

Quando um comando digitado no prompt (ou linha de comando) do Linux, ele dividido em partes, separadas por espa os em branco: a primeira parte o nome do programa, cuja exist ncia ser verificada; em seguida, nesta ordem, v m as op es/par metros, redirecionamentos e vari veis. Quando o programa identificado existe, o Shell verifica as permiss es dos arquivos en-

Shell Programas e Comandos Ncleo ou Kernel Hardware

Completadas todas as tarefas anteriores, o Shell monta a linha de comando, j com todas as substitui es feitas e chama o kernel para execut -la em um novo Shell (Shell filho), que ganha um n mero de processo (PID ou Process IDentification) e fica inativo, tirando uma soneca durante a execu o do programa. Uma vez encerrado este processo (e o Shell filho), o Shell pai recebe novamente o controle e exibe um prompt , mostrando que est pronto para executar outros comandos.

Jamais faa:

$ bash: valor: not found

Neste caso, o Bash achou a palavra valor isolada por espaos e julgou que voc estivesse mandando executar um programa chamado valor, para o qual estaria passando dois parmetros: = e 1000.

www.linuxmagazine.com.br

Agosto 2004

83

LINUX USER

Papo de Botequim

Para tirar aquela sensa o que voc tem quando v um script Shell, que mais parece uma sopa de letrinhas ou um conjunto de hier glifos, vou lhe mostrar os principais caracteres especiais para que voc saia por a como Champollion decifrando a Pedra de Roseta.

$ $

isso mesmo, quando n o desejamos que o Shell interprete um caractere espec fico, devemos escond -lo dele. Isso pode ser feito de tr s maneiras diferentes, cada uma com sua peculiaridade: Apstrofo (): quando o Shell v uma cadeia de caracteres entre ap strofos, ele retira os ap strofos da cadeia e n o interpreta seu conte do.
$ linuxmagazine $ bash: linuxm* no such file U or directory

Viu a diferen a? Aspas (): exatamente iguais ao ap strofo, exceto que, se a cadeia entre aspas contiver um cifr o ($), uma crase (`), ou uma barra invertida (\), estes caracteres ser o interpretados pelo Shell. N o precisa se estressar, eu n o te dei exemplos do uso das aspas por que voc ainda n o conhece o cifr o ($) nem a crase (`). Daqui para frente veremos com muita const ncia o uso destes caracteres especiais; o mais importante entender seu significado.

esperando pelo teclado (Entrada Padr o) e como tamb m n o citei a sa da, o que eu teclar ir para a tela (Sa da Padr o), criando desta forma como eu havia proposto um programa gago. Experimente!

Para especificarmos a sa da de um programa usamos o s mbolo > ou o >> , seguido do nome do arquivo para o qual se deseja mandar a sa da. Vamos transformar o programa anterior em um editor de textos :
$

No primeiro caso o Shell expandiu o asterisco e descobriu o arquivo linuxmagazine para listar. No segundo, os ap strofos inibiram a interpreta o do Shell e veio a resposta que n o existe o arquivo linuxm*. Contrabarra ou Barra Invertida (\): id ntico aos ap strofos exceto que a barra invertida inibe a interpreta o somente do caractere que a segue. Suponha que voc , acidentalmente, tenha criado um arquivo chamado * (asterisco) o que alguns sabores de Unix permitem e deseja remov -lo. Se voc fizesse:
$

A maioria dos comandos tem uma entrada, uma sa da e pode gerar erros. Esta entrada chamada Entrada Padr o ou stdin e seu dispositivo padr o o teclado do terminal. Analogamente, a sa da do comando chamada Sa da Padr o ou stdout e seu dispositivo padr o a tela do terminal. Para a tela tamb m s o enviadas normalmente as mensagens de erro oriundas dos comandos, chamada neste caso de Sa da de Erro Padr o ou stderr. Veremos agora como alterar este estado de coisas. Vamos fazer um programa gago. Para isto digite (tecle Enter ao final de cada linha comandos do usu rio s o ilustrados em negrito):
$ E-e-eu sou gago. Vai encarar?

O cat continua sem ter a entrada especificada, portanto est aguardando que os dados sejam teclados, por m a sua sa da est sendo desviada para o arquivo Arq. Assim sendo, tudo que esta sendo teclado esta indo para dentro de Arq, de forma que fizemos o editor de textos mais curto e ruim do planeta. Se eu fizer novamente:
$

Os dados contidos em Arq ser o perdidos, j que antes do redirecionamento o Shell criar um Arq vazio. Para colocar mais informa es no final do arquivo eu deveria ter feito:
$

Voc estaria na maior encrenca, pois o rm removeria todos os arquivos do diret rio corrente. A melhor forma de fazer o servi o :
$

O cat um comando que lista o conte do do arquivo especificado para a Sa da Padr o (stdout). Caso a entrada n o seja definida, ele espera os dados da stdin (a entrada padr o). Ora como eu n o especifiquei a entrada, ele a est

Desta forma, o Shell n o interpreta o asterisco, evitando a sua expans o. Fa a a seguinte experi ncia cient fica:
$ $

Como j havia dito, o Shell resolve a linha e depois manda o comando para a execuo. Assim, se voc redirecionar a sada de um arquivo para ele prprio, primeiramente o Shell esvaziaeste arquivo e depois manda o comando para execuo! Desta forma, para sua alegria, voc acabou de perder o contedo de seu querido arquivo.

Assim como por padr o o Shell recebe os dados do teclado e envia a sa da para a tela, os erros tamb m v o para a tela se voc n o especificar para onde eles devem ser enviados. Para redirecionar os erros, use 2> SaidaDeErro. Note que entre o n mero 2 e o sinal de maior (>) n o existe espa o em branco. Vamos supor que durante a execu o de um script voc pode, ou n o (dependendo do rumo tomado pela execu o do programa), ter criado um arquivo chamado /tmp/seraqueexiste$$. Como n o quer ficar com sujeira no disco r gido, ao final do script voc coloca a linha a seguir:

84

Agosto 2004

www.linuxmagazine.com.br

Papo de Botequim

LINUX USER

Preste ateno! No confunda >> com 2>. O primeiro anexa dados ao final de um arquivo, e o segundo redireciona a Sada de Erro Padro (stderr) para um arquivo que est sendo designado. Isto importante!

Caso o arquivo n o existisse seria enviado para a tela uma mensagem de erro. Para que isso n o aconte a fa a:
U

caprichamos, n ? Ent o ao inv s de sair redigindo o mail direto no prompt , de forma a tornar imposs vel a corre o de uma frase anterior onde, sem querer, voc escreveu um n s vai , voc edita um arquivo com o conte do da mensagem e ap s umas quinze verifica es sem constatar nenhum erro, decide envi -lo e para tal faz:
$
U

Um erro comum no uso de labels (como o fimftp do exemplo anterior) causado pela presena de espaos em branco antes ou aps o mesmo. Fique muito atento quanto a isso, por que este tipo de erro costuma dar uma boa surra no programador, at que seja detectado. Lembre-se: um label que se preze tem que ter uma linha inteira s para ele.

Para que voc teste a Sa da de Erro Padr o direto no prompt do seu Shell, vou dar mais um exemplo. Fa a:
$ bash: naoexiste no such file U or directory $ $ $ bash: naoexiste no such file U or directory

e o chefe receber uma mensagem com o conte do do arquivocommailparaochefe. Outro tipo de redirecionamento muito louco que o Shell permite o chamado here document . Ele representado por << e serve para indicar ao Shell que o escopo de um comando come a na linha seguinte e termina quando encontra uma linha cujo conte do seja unicamente o label que segue o sinal <<. Veja o fragmento de script a seguir, com uma rotina de ftp:

Neste exemplo, vimos que quando fizemos um ls em naoexiste, ganhamos uma mensagem de erro. Ap s redirecionar a Sa da de Erro Padr o para arquivodeerros e executar o mesmo comando, recebemos somente o prompt na tela. Quando listamos o conte do do arquivo para o qual foi redirecionada a Sa da de Erro Padr o, vimos que a mensagem de erro tinha sido armazenada nele. interessante notar que estes caracteres de redirecionamento s o cumulativos, isto , se no exemplo anterior fiz ssemos o seguinte:
$
U

a mensagem de erro oriunda do ls seria anexada ao final de arquivodeerros.

neste pedacinho de programa temos um monte de detalhes interessantes: As op es usadas para o ftp (-ivn) servem para ele listar tudo que est acontecendo (op o -v de verbose ), para n o ficar perguntando se voc tem certeza que deseja transmitir cada arquivo (op o -i de interactive ) e finalmente a op o -n serve para dizer ao ftp para ele n o solicitar o usu rio e sua senha, pois estes ser o informados pela instru o espec fica (user); Quando eu usei o << fimftp, estava dizendo o seguinte para o interpretador: Olha aqui Shell, n o se meta em

nada a partir deste ponto at encontrar o label fimftp. Voc n o entenderia droga nenhuma, j que s o instru es espec ficas do ftp . Se fosse s isso seria simples, mas pelo pr prio exemplo d para ver que existem duas vari veis ($Usuario e $Senha), que o Shell vai resolver antes do redirecionamento. Mas a grande vantagem deste tipo de constru o que ela permite que comandos tamb m sejam interpretados dentro do escopo do here document , o que, ali s, contraria o que acabei de dizer. Logo a seguir te explico como esse neg cio funciona. Agora ainda n o d , est o faltando ferramentas. do repert rio de O comando user instru es do ftp e serve para passar o usu rio e a senha que haviam sido lidos em uma rotina anterior a este fragmento de c digo e colocados respectivamente nas duas vari veis: $Usuario e $Senha. O binary outra instru o do ftp, que serve para indicar que a transfer ncia de arquivoremoto ser feita em modo bin rio, isto o conte do do arquivo n o ser inteerpretado para saber se est em ASCII, EBCDIC, O comando get arquivoremoto diz ao cliente ftp para pegar este arquivo no servidor hostremoto e traz -lo para a nossa m quina local. Se quis ssemos enviar um arquivo, bastaria usar, por exemplo, o comando put arquivolocal.

Para fazermos o redirecionamento da Entrada Padr o usamos o < (menor que). E pra que serve isso? , voc vai me perguntar. Deixa eu dar um exemplo, que voc vai entender rapidinho. Suponha que voc queira mandar um mail para o seu chefe. Para o chefe n s

O $$ contm o PID,isto ,o nmero do seu processo. Como o Linux multiusurio, bom anexar sempre o $$ ao nome dos seus arquivos para no haver problema de propriedade,isto ,caso voc batizasse o seu arquivo simplesmente como seraqueexiste,a primeira pessoa que o usasse (criando-o ento) seria o seu dono e a segunda ganharia um erro quando tentasse gravar algo nele.

Os redirecionamentos de que falamos at agora sempre se referiam a arquivos, isto , mandavam para arquivo, recebiam de arquivo, simulavam arquivo local, O que veremos a partir de agora, redireciona a sa da de um comando para a entrada de outro. util ssimo e, apesar de n o ser macaco gordo, sempre quebra os

www.linuxmagazine.com.br

Agosto 2004

85

LINUX USER

Papo de Botequim

pipe (que maiores galhos. Seu nome em ingl s significa tubo, j que ele canaliza a sa da de um comando para a entrada de outro) e sua representa o a | (barra vertical).
$ 21

Existem who | wc -l usuarios U conectados

$ /home/meudir /etc $ /home/meudir

O comando ls passou a lista de arquivos para o comando wc, que quando est com a op o -l conta a quantidade de linhas que recebeu. Desta forma, podemos afirmar categoricamente que no meu diret rio existiam 21 arquivos.
$

Hi! Olha s , n o funcionou! mesmo, n o funcionou e n o foi por causa das aspas que eu coloquei, mas sim por que eu teria que ter executado o who | wc -l antes do echo. Para resolver este problema, tenho que priorizar a segunda parte do comando com o uso de crases:
$ Existem conectados 8 usuarios U
U

A linha de comandos acima manda a listagem do arquivo /etc/passwd para a entrada do comando sort. Este a classifica e envia para o lp que o gerenciador da fila de impress o.

Para eliminar esse monte de brancos antes do 8 que o wc -l produziu, basta retirar as aspas. Assim:
$ Existem 8 usuarios conectados
U

Quequeiiisso minha gente? Eu estava no /home/meudir, mudei para o /etc, constatei que estava neste diret rio com o pwd seguinte e quando o agrupamento de comandos terminou, eu vi que continuava no /etc/meudir! Hi! Ser que tem coisa do m gico Mandrake por a ? Nada disso. O interessante do uso de par nteses que eles invocam um novo Shell para executar os comandos que est o em seu interior. Desta forma, fomos realmente para o diret rio /etc, por m ap s a execu o de todos os comandos, o novo Shell que estava no diret rio /etc morreu e retornamos ao Shell anterior que estava em /home/meudir. Que tal usar nossos novos conceitos?
$

Quando queremos priorizar uma express o, n s a colocamos entre par nteses, n o ? Pois , por causa da aritm tica normal pensarmos deste jeito. Mas em Shell o que prioriza mesmo s o as crases () e n o os par nteses. Vou dar exemplos para voc entender melhor. Eu quero saber quantos usu rios est o logados no computador que eu administro. Eu posso fazer:
$ 8

As aspas protegem da interpreta o do Shell tudo que est dentro dos seus limites. Como para o Shell basta um espa o em branco como separador, o monte de espa os ser trocado por um nico ap s a retirada das aspas. Outra coisa interessante o uso do ponto-e-v rgula. Quando estiver no Shell, voc deve sempre dar um comando em cada linha. Para agrupar comandos em uma mesma linha, temos que separ -los por ponto-e-v rgula. Ent o:
$ /home/meudir /etc /home/meudir

U U U U U

O comando who passa a lista de usu rios conectados ao sistema para o comando wc -l, que conta quantas linhas recebeu e mostra a resposta na tela. Muito bem, mas ao inv s de ter um n mero oito solto na tela, o que eu quero mesmo que ele esteja no meio de uma frase. Ora, para mandar frases para a tela eu s preciso usar o comando echo; ent o vamos ver como que fica:

Em Unix existe um arquivo fantasma. Chama-se /dev/null.Tudo que enviado para este arquivo some. Assemelha-se a um Buraco Negro. No caso do exemplo, como no me interessava guardar a possvel mensagem de erro oriunda do comando rm, redirecionei-a para este arquivo.

Neste exemplo, listei o nome do diret rio corrente com o comando pwd, mudei para o diret rio /etc, novamente listei o nome do diret rio e finalmente voltei para o diret rio onde estava anteriormente (cd -), listando seu nome. Repare que coloquei o ponto-e-v rgula de todas as formas poss veis, para mostrar que n o importa se existem espa os em branco antes ou ap s este caracter. Finalmente, vamos ver o caso dos par nteses. No exemplo a seguir, colocamos diversos comandos separados por ponto-e-v rgula entre par nteses:

Finalmente agora podemos demonstrar o que conversamos anteriormente sobre here document . Os comandos entre crases tem prioridade, portanto o Shell os executar antes do redirecionamento do here document . Quando o suporte receber a mensagem, ver que os comandos date e ls foram executados antes do comando mail, recebendo ent o um instant neo do ambiente no momento de envio do email. - Gar om, passa a r gua! s
Julio Cezar Neves Analista de Suporte de Sistemas desde 1969 e trabalha com Unix desde 1980, quando fez parte da equipe que desenvolveu o SOX, sistema operacional, similar ao Unix, da Cobra Computadores. professor do curso de Mestrado em Software Livre das Faculdades Estcio de S, no Rio de Janeiro.

86

Agosto 2004

www.linuxmagazine.com.br

SOBRE O AUTOR