Tag: Bash

Instalando o CouchDB e o Python-CouchDB no Ubuntu 8.10 (Intrepid)

Não a versão do repositório, mas a mais nova.

Só a sequência de comandos, que eu estou com pressa agora:

sudo apt-get install build-essential erlang libicu38 libicu-dev libmozjs-dev automake autoconf libtool help2man libcurl-ocaml-dev subversion python-setuptools
mkdir ~/src
cd ~/src
svn co http://svn.apache.org/repos/asf/couchdb/trunk couchdb
cd couchdb
./bootstrap && ./configure && make && sudo make install
sudo adduser --system --home /var/lib/couchdb --no-create-home --shell /bin/bash --group --gecos "CouchDB Administrator" couchdb
sudo chown -R couchdb /usr/local/var/lib/couchdb/
sudo chown -R couchdb /usr/local/var/log/couchdb/
sudo easy_install simplejson
sudo easy_install httplib2
sudo easy_install couchdb

Brincando com a API do twitter

Resolvi experimentar um pouco a Twitter API. É linda, do jeito que toda API deveria ser. É REST, muito fácil de entender e colocar para funcionar, e devolve dados em XML, JSON, RSS e ATOM.

Essa simplicidade permite interagir com a API usando ferramentas simples da linha de comando do Unix, como o wget e a cURL. Para nossos exemplos, vamos usar cURL. Se você usa Ubuntu, antes de começar faça:

sudo apt-get install curl

Para fazer um simples post, por exemplo, você pode digitar, em seu terminal:

curl -u seu_username:sua_senha -d status="Twittando do terminal. Aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/" http://twitter.com/statuses/update.json

É isso mesmo, meninos e meninas, é só um post com autenticação, mais nada. RESTful, simples e elegante, deixar qualquer SOAP no chinelo. Inspirador para qualquer um que precise projetar uma API. Isso retorna dados em JSON. Se você quiser os mesmos dados em XML, ATOM ou RSS, basta mudar a extensão na url.

Agora vamos automatizar isso. Eu criei um arquivo /usr/local/bin/twitter com o seguinte conteúdo:

source $HOME/.twitter
curl -u $user:$password -d status="$@" http://twitter.com/statuses/update.json

Naturalmente, criei o arquivo como root e dei permissão de execução para todos os usuários. Agora, no diretório de cada usuário, basta criar um arquivo .twitter com o seguinte conteúdo:

user=seu_username
password=sua_senha

Pronto, tendo feito isso, qualquer usuário que tenha o arquivo .twitter em seu home pode twittar do terminal com:

twitter "Twittando do terminal, aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/"

Simples e indolor, agora você pode automatizar suas twittadas com shell script. Pode, por exemplo, twittar toda vez que seu servidor baleiar, ou agendar twits com cron.

Search API

A Search API também é espetacularmente simples, dê uma olhada. Fiz a UPBox usando a Twitter Search API, por exemplo, com 22 linhas de código.

Integrando o Vim com ferramentas externas

Depois que comecei a usar o Vim nas palestras em que eu escrevo código, muita gente começou a me escrever com dúvidas sobre o editorzinho. Apesar de eu dizer nas palestras que Vim é complicado, parece que o pessoal não tem medo. E a dúvida mais freqüente é sobre a integração entre o Vim e ferramentas externas, principalmente o txt2tags.

Faz parte da filosofia Unix que um programa seja facilmente integrado a outros através de interfaces de texto, e o Vim implementa isso muito bem. Para começar, abra o Vim e execute:

:!ls

Você vai ver que o Vim vai executar o comando ls. Então guarde isso, o sinal de exclamação (!) executa comandos externos. Há duas maneiras de fazer o Vim falar com esses comandos. A primeira é mandar o Vim ler a entrada do comando. Digite:

:r!ls

Você vai notar que o Vim vai executar o comando ls e colocar o conteúdo no buffer de edição. A outra maneira de fazer o Vim falar com os programas externos é selecionar texto. Aperte i para ir para o modo de edição e digite:

zebra
tesoura
banana
macaco
felicidade
abacate

Ao terminar de digitar, pressione ESC para voltar ao modo de comando, em seguida SHIFT+V para ir para o modo de seleção de linha e selecione todo o bloco. Com o bloco selecionado, digite:

:!sort

O vim vai colocar, antes do comando, os sinais de seleção ‘<,'>. Não se preocupe, apenas digite o comando e aperte ENTER. Você vai ver que o Vim vai executar o comando sort do sistema operacional, passando como entrada o texto selecionado, e vai substituir esse texto pela saída do comando. Isso, ao final, vai te dar a lista ordenada, assim:

abacate
banana
felicidade
macaco
tesoura
zebra

Usando essa interface simples você pode fazer o Vim falar com qualquer programa Unix.

txt2tags

O programa que eu tenho usado durante as palestras e mais tem deixado as pessoas curiosas é o txt2tags, desenvolvido pelo Aurélio Marinho. O programa está nos repositórios do Debian, então se você usa Debian ou Ubuntu, pode instalá-lo com o comando:

sudo apt-get install txt2tags

O txt2tags lê as primeiras linhas de texto que recebe como títulos do documento. Além disso, precisaremos de várias opções de linha de comando, o que não é conveniente de se digitar. Então vamos criar um shell script para guardar essas opções e fornecer ao txt2tags linhas de cabeçalho de mentirinha. Eu criei um arquivo chamado tags dentro do diretório /usr/local/bin, com permissão de execução (chmod +x) e o seguinte conteúdo:

#!/bin/bash
(echo "
 
 
 
 
 
" && cat ) | txt2tags -t xhtml --infile=- --no-headers

Em seguida, basta abrir o Vim e digitar, por exemplo:

= Aprenda Online =
A [Visie http://visie.com.br/] oferece cursos de Ajax, Javascript e Tableless.

Em seguida selecione essas duas linhas e execute:

:!tags

Pronto, HTML instantâneo.

Dicas de shell: testes unitários e commit

Todas as tarefas relacionadas a contrução, teste e publicação de um desenvolvimento de software[bb] 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[bb] que, antes de enviar o código, executa todos os testes unitários. Vou trabalhar com Python[bb], 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"

Dicas de shell: find

Um dos comandos mais úteis no gerenciamento de arquivos no terminal do Linux[bb] é 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[bb].
  • -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[bb] 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.

Ssh, sftp e rsync em porta diferente do padrão

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[bb], 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[bb], 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

Quem tem medo do terminal?

Estava ajudando um amigo a instalar o Ubuntu[bb] 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[bb], 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?

Linux? Windows? Dreamweaver? Photoshop?

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[bb](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[bb], 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[bb] 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.

Revista Guia do Hardware

Revista Guia do Hardware

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[bb], 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[bb]. 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[bb] 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!