Como adicionar uma string no final de cada linha

Peguei um arquivo com um script SQL que não estava com ";" no final de cada instrução. O arquivo tinha por volta de 500 mil linhas.
Pesquisando como resolver o problema achei duas formas interessantes, práticas e parecidas:

1) usando o 'sed'

sed -i 's/$/;/' filename

2) usando o 'vi'

:%s/$/;/g

Nas minhas buscas no Google encontrei outras formas de fazer a mesma coisa usando desde Perl até Java. É melhor o sed/vi mesmo =)

Usando Python para testar envio de e-mails

Existem certas situações em que nós estamos desenvolvendo algum sistema que precisa enviar e-mail. Mas durante os testes não há necessidade de enviar os e-mails realmente.

Uma solução simples e legal é usar um servidor de e-mail "de mentira", que funciona como um servidor SMTP real, recebe a mensagem porém não faz a entrega.

Com o Python é possível simular um servidor SMTP com apenas uma linha de comando:

python -m smtpd -n -c DebuggingServer localhost:1025

Este comando irá iniciar um servidor SMTP que ficará ouvindo a porta 1025. Este servidor irá mostrar toda a saída dos cabeçalhos e corpo do e-mail enviado.

Para mais informações sobre esta funcionalidade, visite:
http://docs.python.org/library/smtpd.html

Tirei esta dica da documentação do Django:
http://docs.djangoproject.com/en/dev/topics/email/#testing-e-mail-sending

Como gerar Locales no Linux (Mint/Ubuntu)

Eu estava precisando do locale pt_BR para o desenvolvimento de uma parte de um sistema, mas no meu Linux (Mint 7) tinha somente os locales en_XX

Executando o comando locale -a você poderá ver todos os locales instalados no seu computador.

Pesquisando no Google, eu encontrei uma dica de como gerar os locales:

$ sudo locale-gen pt_BR.UTF-8
Generating locales…
pt_BR.UTF-8… done
Generation complete.

$ sudo dpkg-reconfigure locales
Generating locales…
en_AU.UTF-8… done
…
en_ZW.UTF-8… done
pt_BR.UTF-8… up-to-date
Generation complete.

Além disso, eu também precisava o locale pt_BR-ISO-8859-1, mas ele não estava sendo gerado com o comando locale-gen, mesmo ele sendo suportado, de acordo com o arquivo localizado em /var/lib/locales/supported.d/SUPPORTED.

Então, abri o arquivo /var/lib/locales/supported.d/local e adicionei a seguinte linha:

pt_BR.ISO-8859-1 ISO-8859-1

Meu arquivo ficou com este conteúdo:
$ sudo vi /var/lib/locales/supported.d/local

en_US.UTF-8 UTF-8
pt_BR.UTF-8 UTF-8
pt_BR.ISO-8859-1 ISO-8859-1

Depois de todos estes passos eu rodei novamente os comandos:
$ sudo dpkg-reconfigure locales
$ locale -a

Esses passos foram executados no Linux Mint 7 e no Ubuntu 9.04, mas com algumas adaptações dá para ser utilizada em outras distros. Caso tenha feito em outra distro, envie como comentário as diferenças.

Até +

Escavações

Faz tempo que não posto nada por aqui... então para não ficar muito parado segue este estudo que fizeram:

Durante escavações nos Estados Unidos, arqueólogos descobriram, a 100 m de profundidade, vestígios de fios de cobre que datavam do ano 1000. Os americanos concluíram que seus antepassados já dispunham de uma rede telefônica naquela época!

Os japoneses, para não ficarem para trás, escavaram também seu subsolo, encontrando restos de fibras ópticas a 200 m de profundidade. Após minuciosas análises, concluíram que elas tinham 2.000 anos de idade. Os japoneses concluíram, triunfantes, que seus antepassados já dispunham de uma rede digital a base de fibra óptica quando Jesus Nasceu!

Uma semana depois, em Portugal , foi publicado o seguinte anúncio: “Após escavações arqueológicas no subsolo de Lisboa, Coimbra, Pombal, Bragança, Faro, Aveiro, Porto, Guimarães, Fátima, Setúbal e diversas outras cidades portuguesas até uma profundidade de 500 metros, os cientistas portugueses não encontraram absolutamente nada.”

Assim se conclui que os Portugueses já dispunham, há 5.000 anos, de uma rede de comunicações sem-fio: wireless!

Configurando teclas multimídia no Xfce

Já estou utilizando a algumas semanas o Xfce 4.6 no openSUSE e o Xfce 4.4 no Ubuntu e não tenho o que reclamar. Realmente o sistema é bem mais leve que os badalados Kde e Gnome. Se você quer ter um desktop simples, funcional e, principalmente, não tem muita RAM disponível vale a dica!

Bom, depois da instalação tudo estava funcionando perfeitamente, exceto as teclas de controle multimídia do notebook. As outras teclas de controle, por exemplo, aumentar/diminuir o brilho da tela estavam funcionando ok.

Apenas como observação, esta problema ocorreu no Xfce 4.4 rodando no Ubuntu 8.04.
Outro detalhe, este problema não chega a ser um "bug". O que acontece é que o Xfce veio configurado para utilizar o aumix para controlar o som e eu estou só com o amixer instalado. Então a solução era instalar o aumix ou reconfigurar a tecla para usar o amixer. Apesar da primeira opção ser mais simples (apt-get install aumix), optei pela segunda, que também não é nenhum bicho de sete cabeças. Lá vai:

- Em Settings vá na opção Keyboard Settings (Configurações de Telcado)
- Selecione a aba Shortcuts (Atalhos)

Você verá que já existe um tema default, porém está "read-olny".
Então adicione um novo tema e dê um nome criativo para ele (exemplo: "meu_tema")

Remova os 3 atalhos que utilizam o aumix.
Em seguida adicione um novo passando o seguinte comando:

amixer set Master toggle

Quando você confirmar ele vai ficar esperando que você pressione o conjunto de teclas para executar este comando. Portanto pressione a tecla correspondente ao mudo. No meu notebook é o conjunto Fn+End.

Se você já estiver escutando alguma música já dá para testar se a tecla está funcionando corretamente. Estando tudo nos conformes então repita os passos acima para aumentar / diminuir o volume.

amixer set Master 5+

amixer set Master 5-

É só isso! Tão simples quanto o próprio Xfce.

Problema no Xfce 4.6 resolvido

Eu estava usando o Xfce 4.4 no meu openSUSE 11.1 e tudo estava mil maravilhas. Realmente ele é muito prático, leve e funcional. Vale a pena.

Até que na semana passada eu adicionei o repositório Xfce do openSUSE para fazer o upgrade da versão 4.4 para a 4.6 (lançada no final de fevereiro). A instalação correu sem problemas através do Yast. Terminada a instalação reiniciei o micro e tive a desagradável surpresa quando fiz o login: o Xfce ficou absurdamente lento para carregar. O splash screen do Xfce demorava uns 2 minutos para desaparecer.

Essa demora para inicializar não deveria ser normal. Então escrevi um e-mail detalhando o problema para o mantenedor dos pacotes Xfce para o openSUSE e ele sugeriu uma dica: apagar o diretório sessions do Xfce. Esse diretório fica dentro do diretório oculto cache no home do usuário:

~/.cache/sessions

Feito isso reiniciei a máquina e, dessa vez, tive a agradável surpresa de ver o splash screen por pouquíssimos segundos. Xfce rápido novamente! =)

Referências:
http://download.opensuse.org/repositories/X11:/xfce/openSUSE_11.1/
http://www.xfce.org/about/news?id=21
http://en.opensuse.org/X11:xfce

Templates para erros 404 e 500 no Django

Se você está com problemas com o template para exibir quando ocorrer o erro 500 talvez este post pode ser útil. Vamos lá!

Durante o desenvolvimento com Django, a variável DEBUG do arquivo settings.py fica com o valor True. Isto é útil pois quando ocorre algum erro, o Django nos mostra uma página com detalhes do erro, as chamadas dos métodos, valores de variáveis, etc.

Mas quando colocamos o sistema para rodar no servidor de produção devemos colocar DEBUG como False, pois o sistema já está pronto e sem problemas (hum... pelo menos deveria).

Mas caso ocorra algum erro de página não encontrada (erro 404) ou erro no servidor (erro 500) precisamos criar um template para mostrar uma mensagem amigável ao usuário. E o Django, como era de se esperar, já nos oferece os devidos templates prontos. Basta criar os arquivos 404.html e 500.html na raíz do diretório de templates e fazer uma chamada ao modelo pronto do Django. Cada arquivo irá conter apenas uma linha:

404.html:
{% extends "admin/404.html" %}

500.html:
{% extends "admin/500.html" %}

Isto já é (ou deveria ser) o suficiente para quem não quer ter o trabalho de montar suas próprias páginas de erros. A página de erro 404.html funciona perfeitamente. Nada o que reclamar. Porém a página 500.html não aparece "direito". É como se os arquivos estáticos (css, imagens, etc) não fossem lidos.

Pesquisando no Google descobri que nos casos onde ocorre erro 500 o Django não passa o RequestContext para o template. Consequentemente algumas variáveis não ficam disponíveis dentro do template, entre elas a MEDIA_URL.

Para contornar este problema a solução indicada foi re-escrever a view do Django que chama o template 500.html passando o MEDIA_URL. A view original está localizada em:

/caminho-para-seu-django/django/views/defaults.py

Dentro deste arquivo tem a função 'server_error'. Basta copiar esta função modificando apenas a linha do 'return'. O arquivo ficará assim:


from django.conf import settings
from django import http
from django.template import Context, loader

def server_error(request, template_name='500.html'):
"""
500 error handler.

Templates: `500.html`
Context:
MEDIA_URL
Path of static media (e.g. "media.example.org")
"""
# You need to create a 500.html template.
t = loader.get_template(template_name)
return http.HttpResponseServerError(
t.render(Context({'MEDIA_URL': settings.MEDIA_URL})))

Agora é só salvá-lo em algum lugar no seu projeto. No meu caso, criei uma view na raíz do projeto. Depois, dentro do arquivo urls.py coloque a seguinte linha:

handler500 = 'seuprojeto.views.server_error'

Isso já é o suficiente. Uma vez que a variável DEBUG do settings.py esteja como False, a página de erro 500 será mostrada sem problemas. Além disso, caso as configurações de Email estejam configuradas no settings.py você receberá detalhes do erro em seu e-mail.

Mas é claro, assim como plano de saúde e seguro de automóvel, nós criamos o template 500 esperando que ele nunca seja utilizado =)