fechaTag

No Greg's Wiki você encontra os Bash Pitfalls, uma lista de problemas comuns entre os programadores bash iniciantes.

Encontrei vários dos meus erros comuns lá. E aprendi um bocado.

Todas as tarefas relacionadas a contrução, teste e publicação de um desenvolvimento de software devem ser automatizadas o máximo possível. Escrever software é interar. Você escreve e testa, escreve e testa, escreve e testa dezenas, às vezes centenas de vezes por dia. As tarefas relacionadas a testar o software, de maneira especial, merecem a automatização que for possível dar a elas. Convenhamos, testar é algo muito chato. E se for complicado testar, será uma tentação irresistível para o programador entregar seu código sem testar adequadamente.

Hoje vamos construir um script de commit no subversion que, antes de enviar o código, executa todos os testes unitários. Vou trabalhar com Python, mas você não deve ter dificuldades em adaptar isso para a sua linguagem de programação predileta.

A primeira coisa importante é que você entenda que todo script executado no shell tem um valor de retorno. Esse valor é retornado pelo comando, e também armazenado na variável especial $?. Veja estes exemplos:

$ echo $?
2
$ ls test
test
$ echo $?
0
$ if ls test2;then echo O arquivo existe.;fi
ls: test2: Arquivo ou diretório não encontrado
$ if ls test;then echo O arquivo existe.;fi
test
O arquivo existe.
$ if ! ls test;then echo O arquivo não existe.;fi
test
$ if ! ls test2;then echo O arquivo não existe.;fi
ls: test2: Arquivo ou diretório não encontrado
O arquivo não existe.

Os testes foram construídos usando o módulo para testes unitários unittest do Python. Cada teste está, no diretório do projeto, junto do arquivo de código que ele testa. E o nome dos arquivos de teste sempre começam com "test". Assim, o arquivo connections.py é testado pelo testconnections.py.

Veja então nosso shell script, salvo com o nome de commit, que será usado durante todo o projeto para rodar os testes antes do commit:

#!/bin/bash
 
# Começamos com um contador de erros em zero
erros=0
 
# Encontramos cada um dos testes
for i in `find -name "test*.py"`;do
echo TESTANDO: $i
echo
 
# Se o teste falhar, incrementamos a variável erros
if ! python $i;then
erros=$(($erros + 1))
fi
 
echo
done
 
# Se os testes passaram, fazemos commit, caso contrário
# avisamos o usuário
if [ $erros == 0 ];then
# Esse $* passa os parâmetros de linha de comando recebidos para o svn.
svn ci $*
else
echo Testes falharam, commit cancelado.
fi

Tendo feito isso, e colocando esse script em /usr/local/bin, o programador vai trocar svn ci por commit, e os testes serão feitos automaticamente antes do commit. Ele também pode passar parâmetros do svn para o script:

commit -m "Criei o link espacial com saturno"

Um dos comandos mais úteis no gerenciamento de arquivos no terminal do Linux é o comando find. Ele permite realizar e automatizar tarefas que na interface gráfica levariam muito tempo. Executar o comando find sem argumentos faz com que ele liste todos os arquivos do diretório atual e de seus subdiretórios.

Para procurar dentro de um diretório específico, informe o caminho ao find:

find caminho/onde/procurar

O find recebe uma série de parâmetros úteis. É bom lembrar que o diretório de procura precisa ser sempre o primeiro parâmetro. Assim, para procurar por todos os arquivos de extensão bak no diretório atual, faça:

find -name "*.bak"

E para procurar dentro de um diretório específico, use:

find caminho/onde/procurar -name "*.bak"

O find permite a você construir uma série de expressões de procura e operação com os arquivos, algumas bastante complicadas (e poderosas). Vamos dar uma olhada em algumas bem simples. Para apagar os arquivos, use -delete. Então, para apagar todos os arquivos bak no diretório atual e em seus subdiretórios, faça:

find -name "*.bak" -delete

Você também pode passar parâmetros numéricos, que funcionam segundo a seguinte lógica:

• Um número sozinho significa exatamente aquele número, por exemplo: 3
• Com um sinal de mais, significa maior do que aquele número: +3
• Com um sinal de menos, significa menor do que aquele número: -3

Para ver uma lista dos arquivos modificados há menos de três dias, faça:

find -mtime -3

Para ver os que foram modificados a mais de três dias, inverta o sinal:

find -mtime +3

As expressões mais comuns para uso com tempo são:

• -amin - quando o arquivo foi acessado, em minutos.
• -atime - quando o arquivo foi acessado, em dias.
• -cmin - quando o arquivo foi criado, em minutos.
• -ctime - quando o arquivo foi criado, em dias.
• -mmin - quando o arquivo foi modificado, em minutos.
• -mtime - quando o arquivo foi modificado, em dias.

Outras expressões bastante úteis são:

• -regex: funciona como -name, mas recebe uma expressão regular.
• -size: filtra pelo tamanho do arquivo. É um número seguido de uma letra. As mais comuns são: c - bytes, k - kilobytes, M - megabytes e G - gigabytes.

Por fim, você também pode mandar o find executar operações nos arquivos. Foi o que fizemos no início, quando usamos -delete para apagar arquivos. Dentre as operações, minha predileta é a -exec.

Quando você coloca -exec numa linha de comando do find, tudo o que vem depois até o próximo ";" é entendido pelo find como um comando, que ele vai executar para cada um dos arquivos encontrados. É obrigatório colocar ";" para terminar o comando, se você se esquecer vai receber o seguinte erro:

$ find -exec ls
find: faltando argumento para `-exec'

Onde você quiser passar para seu comando o nome do arquivo, use {}. Por exemplo, para tirar a permissões de execução de todos os arquivos TXT na busca, você pode fazer:

find -name "*.txt" -exec chmod -x {} ";"

Isso vai executar, para cada um dos arquivos encontrados:

chmod -x ARQUIVO ;

O último truque que eu gostaria que você guardasse na manga é que você pode combinar o find com o excelente comando grep. Grep faz buscas dentro de um arquivo. Com o parâmetro -l o grep apenas lista o nome do arquivo se a expressão regular de busca for encontrada. Então, para encontrar todos os arquivos python que contém o texto "urllib" você pode fazer:

find -name *.py -exec grep -l urllib {} ";"

O find, é claro, tem muito mais recursos e opções. Se quiser mesmo se aprofundar, man find.

Levei mais tempo do que devia para achar essa solução, então vou deixar registrada aqui, pois pode ter mais gente atrás disso. O protocolo ssh é muito popular no mundo Unix. Com ele você pode administrar seu servidor à distância. O tráfego de dados ssh é todo criptografado, e o protocolo é bastante seguro. Mesmo assim, se você tem usuários em sua máquina com senhas fracas, corre o sério risco de sofrer um ataque de dicionário.

Entre as principais recomendações para tornar seu servidor mais seguro estão:

• Evite senhas fracas: faça com que seus usuários tenham senhas fortes e não óbvias;
• Não permita o login como root: assim, para fazer alguma coisa realmente perigosa, um invasor teria que descobrir duas senhas ao invés de uma. No Ubuntu, edite o arquivo /etc/ssh/sshd_config e altere a linha PermitRootLogin para:

  PermitRootLogin no

• Mude a porta do serviço ssh: a porta padrão para o serviço ssh é a 22. Trocá-la vai dar algum trabalho a um possível invasor. Para isso, no Ubuntu, edite o /etc/ssh/sshd_config e altere o número na linha Port para a porta desejada:

  Port 999

Para se conectar ao servidor, use:

ssh -p999 servidor

Como o protocolo ssh é robusto, seguro e flexível, há vários serviços que rodam sobre ele. Entre os mais populares estão o sftp e o rsync. O sftp é um serviço de ftp sobre ssh. A principal vantagem dele em relação ao ftp comum é que o tráfego é criptografado. Já o serviço rsync é genial, serve para manter sincronizadas cópias de arquivos e diretórios em máquinas diferentes.

Para se conectar via sftp com uma porta diferente da 22, use:

sftp -oPort=999 servidor

Para fazer rsync via ssh numa porta diferente da 22, use:

rsync –rsh='ssh -p42' arquivolocal servidor:/caminho/para/o/arquivoremoto

Se você é usuário de Mac OS X, abra um terminal e digite:

$ say hello

Divertido.

Estava ajudando um amigo a instalar o Ubuntu em sua máquina, tentando evitar, a todo custo, me conectar por ssh. E tentando evitar também o uso de terminal, pois meu amigo estava migrando de Windows e parecia ter um certo receio da tela preta. Tivemos alguns problemas com o Automatix, e entrei no canal #ubuntu-br da Freenode para perguntar. Fiquei impressionadíssimo com a solicitude das pessoas que estavam online. Uso bastante irc, e é comum estar em canais sobre Python, SQLObject, Javascript e etc. E sei que geralmente quem se dá ao trabalho de estar ali é porque realmente gosta de ajudar. Mas o pessoal da #ubuntu-br foi especialmente paciente e atencioso.

Depois que desconectei, recebi até um e-mail do Vinícius Depizzol sanando as dúvidas que haviam ficado pendentes. Obrigado Vinícius, obrigado ao pessoal do #ubuntu-br.

Uma das coisas que o Vinícius me mostrou é que eu não preciso de Automatix. Quase tudo o que se faz por ele pode ser feito pelo Ubuntu, na interface gráfica, sem nenhum programa especial. Boa parte no menu "Aplicações" -> "Adicionar/Remover". E o que não dá para resolver lá geralmente é muito fácil de fazer no terminal.

Isso me fez pensar. Nós, programadores, sabemos que o terminal (shell, console ou como você preferir chamá-lo) é a ferramenta mais poderosa dos sistemas Unix. Não há outra maneira de se obter a rapidez e flexibilidade que se tem num terminal.

Estes dias vi um amigo fazendo algo curioso. Ele precisa copiar uma pasta no servidor, chamada "site", para "sitenovo", para começar a trabalhar no novo site. Ele se conectou por FTP, copiou a pasta inteira para a sua máquina (eram alguns megabytes) renomeou e enviou de novo para o servidor. Mais de meia hora de trabalho. Ele poderia ter se conectado via SSH e feito:

cp -r site sitenovo

E em menos de um minuto a cópia estaria feita.

Claro, isso não é novidade nenhuma para o usuário de Linux que já lida com o terminal há algum tempo. Um administrador de sistemas Linux é uma pessoa muito mais feliz graças ao terminal. Mas como fazer com que o usuário de interface gráfica, que não tem gosto pela linha de comando, não perca o tempo que meu amigo perdeu? Como fazer com que o webdesigner que publica arquivos num servidor remoto aprenda pelo menos o básico? Que ele saiba copiar, mover, apagar e editar arquivos e diretórios, navegar por diretórios, sincronizar diretórios, comparar arquivos, criar pequenos scripts para automatizar tarefas e editar o seu crontab?

Uma interessantíssima lista de recursos, sites, extensões, serviços online e outras ferramentas preciosas para o desenvolvedor:

A Roundup for "Developers, Developers, Developers…"

E, aproveitando, um recurso interessante para quem, como eu, está se apaixonando pelo VI, ou apenas quer aprender:

Vim Introduction and Tutorial

Seria assim.

Duas dúvidas que recebi por e-mail hoje, com temas muito semelhantes. Embora eu não sinta falta de nada em meu notebook com Ubuntu, você vai notar que, nas duas respostas recomendei o Mac. Para quem quer trabalhar com Unix mas não pode abrir mão de MS Office, Dreamweaver ou Photoshop, é uma escolha que não se pode deixar de considerar.

eu como desenvolvedor web, dependente de softwares como DreamWeaver(esse aqui nem é problema, é mais o photoshop mesmo rsrs) e Photoshop, gostaria de um motivo ou alguns para migrar para o linux e me tornar um desenvolvedor 100% linux, utilizando só softwares de desenvolvimento do linux.

Que vantagens teria? preciso de uma luz, se puder me dar uma dica fico grato pela atenção.

Olá, como vai?

Minha resposta, naturalmente, vai ser pessoal e baseada em minha experiência. Sugiro que você instale Linux em dual-boot com Windows em sua máquina e descubra por você mesmo se ele serve para você. Sugiro que comece com uma distro fácil de usar, como o Ubuntu ou o Suse.

Para mim a principal vantagem em desenvolver usando Linux é o fato de ter um ambiente de desenvolvimento completo em minha máquina. Meu notebook tem Ubuntu com Apache, MySQL, Postgre, PHP, Python, PSE e Django. Trabalhando assim, e com Subversion, e usando os flexíveis recursos do bash, torno o desenvolvimento muito mais simples. E tenho exatamente as mesmas versões de cada uma dessas ferramentas que terei no servidor de produção.

Outras boas vantagens são a possibilidade de automatizar processos com bash, comandos como find, grep, sed, tail, e, claro, o rsync. Para quem, como eu, trabalha em mais de uma máquina, rsync e svn são tudo. Além disso, tem o ssh. Não sei mais viver sem ssh.

Mas, para rodar Photoshop ou Dreamwever, vai precisar usar algum tipo de emulador ou virtualizador. Vai ter bugs, ou queda de performance, ou os dois Não é problema para mim, porque não uso nenhum dos dois.

Naturalmente, você pode ter um ambiente muito semelhante trabalhando com Windows, principalmente usando o CygWin. E, se você se sente produtivo e confortável trabalhando com Windows, não precisa migrar. De quebra, ainda vai ter Photoshop e Dreamweaver rodando legais.

Outra excelente alternativa é, se você tiver condições para isso, um Mac. Num Mac com chip Intel você pode ter um sistema Unix completo, rodando nativamente Dreamweaver e Photoshop. E, se precisar, pode rodar Windows numa janelinha com o Parallels.

Estou modificando a estrutura de minha empresa e vou vender meu servidor (que é Debian) e minha estação para trabalhar com um notebook, pois preciso de mobilidade. Mas não vivo mais sem o Linux e pretendo instalá-lo no novo equipamento.

Vc me aconselha utilizar o Ubuntu??? Vejo sempre vc falando sobre ele em seus posts. Utilizando o Linux, consigo rodar dentro de um emulador softwares para Windows, como Photoshop e Dreamweaver, dos quais ainda dependo?

Salve, como vai?

Eu uso Ubuntu em meu notebook, e também no Desktop. Para mim, hoje, é a distribuição mais fácil de usar. Mas isso depende de seu perfil de usuário. Se você quiser performance a qualquer custo, vai preferir Gentoo. Se gosta de KDE, vai preferir o Suse (o Kubuntu é meio esquisito, na minha opinião.) E etc.

Agora, em relação ao Photoshop e Dreamweaver, depende de seu perfil de uso. Se você usa pouco esses softwares, pode tê-los rodando no Wine ou VMWare. A performance cai muito, mas é um quebra-galho razoável. Já se você trabalha bastante com eles, vai precisar de Windows em seu notebook. Você pode, por exemplo, trabalhar com dual-boot. Ou pode usar Windows e instalar Apache, PHP, Python e MySQL. E CygWin. Você vai ter até bash no seu Windows.

Uma outra excelente solução, se você puder, é comprar um MacBook. Você vai ter um sistema Unix que roda Dreamweaver e Photoshop. E vai poder rodar Windows ou Linux numa janelinha, com o Parallels.

Tentei o IPython, mas não consegui acostumar com ele. É diferente demais do shell padrão.

Mas hoje, encontrei nos comentários deste artigo, a dica. Ao abrir o shell interativo, rode:

import readline
import rlcompleter
readline.parse_and_bind("tab: complete")

Pronto, isso te dá auto-completar no shell.

Déjà Vu? PowerShell? « Pih is All
Artigo excelente.

Nos comentários, essa jóia:

.NET é aquela maravilhosa tecnologia feita para portar programas Windows para outros Windows

…desde que sejam mais recentes que Windows XP

A revista Guia do Hardware.net é uma proposta inovadora. Uma revista digital, produzida com o mesmo cuidado e qualidade de uma revista impressa, contendo artigos e tutoriais aprofundados sobre hardware, redes e Linux, porém distribuída gratuitamente :). É só acessar o http://guiadohardware.net/revista/ e baixar a sua todos os meses. Não existem condições nem limitações. Você pode baixar, indicar para seus amigos, imprimir as matérias que mais gostar e assim por diante.

A longo prazo a meta é equilibrar os custos da revista com anúncios, mas, por enquanto, ninguém está preocupado com isso, estamos trabalhando no que gostamos e fazendo algo novo.

Acabo de baixar a primeira edição. Excelente. A reportagem "Linux: usando o terminal", por exemplo, tem 24 páginas é uma verdadeira introdução ao Linux, que recomendo para qualquer um que esteja iniciando no mundo Unix. A "História da informática" tem 28 páginas e está primorosa. São mais de 100 páginas de excelente conteúdo.

É uma primeira edição, então há seus probleminhas. O projeto gráfico precisa melhorar um bocado, para ficar próximo ao da Tux Magazine, por exemplo. As páginas de texto claro sobre fundo escuro tornam a impressão inviável. Senti falta também de um feed RSS ou até uma (argh!) newsletter para ser avisado quando sair o número 2. A despeito disso, uma excelente iniciativa. Ao que parece, a revista é feita por apenas quatro pessoas. Muito, muito obrigado pessoal, ficou muito bom!