Phperl, minha gambiarra para usar Perl como se fosse PHP
Admiro muito o PHP, mas só isso, porque eu prefiro construir minhas páginas usando CGI/Perl, então eu bolei uma técnica para poder programar em CGI/perl como se fosse PHP, ou seja, usando um construtor WYSIWYG (Dreamweaver,NVU, etc).
[ Hits: 27.082 ]
Por: Arnaldo Luiz Estevao em 22/01/2008
Explicação passo a passo
Repare como ficará o script após a substituição das tags:
<html><body>
];
print "Hello World !!" ;
print qq[
</body></html>
Depois de embutido:
print qq[<html><body>
];
print "Hello World" ;
print qq[
</body>></html>];
Melhorando a visualização:
print qq[<html><body>];
print "Hello World!";
print qq[</html></body>];
Ok, mas você não quer apenas dizer "Alo mundo" não é? Então vamos construir um form e uma tabela usando esta técnica, eu vou alterar apenas o helloworld.perl.php.
<html><body>
];
print "Hello World !!" ;
print qq[
</body></html>
Depois de embutido:
print qq[<html><body>
];
print "Hello World" ;
print qq[
</body>></html>];
Melhorando a visualização:
print qq[<html><body>];
print "Hello World!";
print qq[</html></body>];
Ok, mas você não quer apenas dizer "Alo mundo" não é? Então vamos construir um form e uma tabela usando esta técnica, eu vou alterar apenas o helloworld.perl.php.
Páginas do artigo
1. Introduzindo2. O interpretador PHPerl
3. helloworld.cgi e helloworld.perl.php
4. Explicação passo a passo
5. helloworld.perl.php (2º exemplo)
Outros artigos deste autor
XML de NF-e ou CT-e ou MDF-e - Como validar usando os pacotes de esquemas do Governo
Instalando Slackware 11.0 em um pendrive
Autenticação mútua SSL em servidores de NF-e e CT-e
Leitura recomendada
Executando os principais frameworks Perl no cPanel com CGI
Catalyst Framework Perl - Parte III
Catalyst Framework Perl (parte 1)
Introdução a CGI com a RFC 3875
Programando uma Intranet com Apache, MySQL e Perl (parte 1)
Comentários
[1] Comentário enviado por hugoeustaquio em 22/01/2008 - 13:48h
PATAQUEOPARÉU!!! Procure um sistema de templates para o perl, que você vai ter todas essas vantagens sem fazer tamanha gambiarra medonha!
PATAQUEOPARÉU!!! Procure um sistema de templates para o perl, que você vai ter todas essas vantagens sem fazer tamanha gambiarra medonha!
[2] Comentário enviado por removido em 22/01/2008 - 13:52h
HAUAHAUHAUAHUAHAUHAUAHHAUAHAUHAUAHUAHAUH
O pulo do gato foi ótimo!!!
Cara, perfeito seu artigo, tô rindo até agora!!!
Cada um que vemos na internet!!! Parabéns, excelênte artigo!
=)
HAUAHAUHAUAHUAHAUHAUAHHAUAHAUHAUAHUAHAUH
O pulo do gato foi ótimo!!!
Cara, perfeito seu artigo, tô rindo até agora!!!
Cada um que vemos na internet!!! Parabéns, excelênte artigo!
=)
[3] Comentário enviado por Ragen em 22/01/2008 - 16:07h
Amigão, nem por acaso você procurou pra ver se isso já não existia algo desse tipo?
Existe um módulo para Apache chamado mod_perl que tem a mesma função do mod_php que está disponível na grande maioria das distros atuais ^^
Ao invés de criar um Frankenstein, você poderia ter documentado como se faz a instalação desse tal módulo, um programa teste ou coisa do tipo.
E só pra finalizar... É sério, devem existir pelo menos uma dúzia de engines de template pra Perl - reinventar a roda, você deve ter muito tempo sobrando!
Amigão, nem por acaso você procurou pra ver se isso já não existia algo desse tipo?
Existe um módulo para Apache chamado mod_perl que tem a mesma função do mod_php que está disponível na grande maioria das distros atuais ^^
Ao invés de criar um Frankenstein, você poderia ter documentado como se faz a instalação desse tal módulo, um programa teste ou coisa do tipo.
E só pra finalizar... É sério, devem existir pelo menos uma dúzia de engines de template pra Perl - reinventar a roda, você deve ter muito tempo sobrando!
[4] Comentário enviado por marcosmiras em 22/01/2008 - 16:42h
hehe...
O gato tá mais pra canguru... rs. O que o Ragen falou é muito considerável, ao invés de "reelaborar a roda" o ideal seria verificar um engine de template disponível...
hehe...
O gato tá mais pra canguru... rs. O que o Ragen falou é muito considerável, ao invés de "reelaborar a roda" o ideal seria verificar um engine de template disponível...
[5] Comentário enviado por leandro_hamid em 22/01/2008 - 20:17h
"Pulo do gato"!?, que é isso cara!!!!
"Pulo do gato"!?, que é isso cara!!!!
[6] Comentário enviado por arnaldoestevao em 24/01/2008 - 16:29h
O problema não esta no fato de eu não saber que existem outras soluções alem do php e sim da maioria dos editores WYSIWYG não saberem disso, o próprio Kompozer por exemplo exibe todas as tags que voce tentar colocar como perl embebido usando o módulo Embperl, além disso eu não reinventei nada tudo que fiz foi construir uma técnica de programação utilizando os próprios recursos e o poder que a que a linguagem Perl oferece sem utilizar nenhum módulo adicional para isso, mas quem não gostou que faça do seu próprio jeito , afinal nós usamos software livre.
O problema não esta no fato de eu não saber que existem outras soluções alem do php e sim da maioria dos editores WYSIWYG não saberem disso, o próprio Kompozer por exemplo exibe todas as tags que voce tentar colocar como perl embebido usando o módulo Embperl, além disso eu não reinventei nada tudo que fiz foi construir uma técnica de programação utilizando os próprios recursos e o poder que a que a linguagem Perl oferece sem utilizar nenhum módulo adicional para isso, mas quem não gostou que faça do seu próprio jeito , afinal nós usamos software livre.
[7] Comentário enviado por hugoeustaquio em 24/01/2008 - 17:26h
Calma colega, não estamos tentando denegrir sua imagem, somente colocando sugestões melhores. Com certeza usando um sistema de templates você não passará por esse problema, pois com template você separa a visualização do código, mantendo os html's limpos.
Calma colega, não estamos tentando denegrir sua imagem, somente colocando sugestões melhores. Com certeza usando um sistema de templates você não passará por esse problema, pois com template você separa a visualização do código, mantendo os html's limpos.
[8] Comentário enviado por arnaldoestevao em 24/01/2008 - 17:57h
Blz Eustáquio, mas manter o código totalmente separado também não é solução, a soluçaõ mais próxima que eu encontrei foi o EmbPerl, mas veja quando voce usa as tags [+ +] o kompozer por exemplo não entende que deva ignorar o conteúdo dentro desta tag, veja um exemplo clássico voce precisa construir uma tabela com linhas de cores de fundo diferente, geralmente o Webdesigner não sabe nada de código se ele não estragar o código ja ajuda muito e o programador é igual ao windows 3.0 ou seja só encherga 16 cores , eu preciso integrar o serviço dos dois, no mercado eu so encontro desenhistas que produzem 90% de seus contúdos usando Dreamweaver, e programadores só em PHP quando encontro. vejamos o caso da tabela multicor
<html>
<body>
<table>
<tr><td>cabeçalho</td></tr>
<?php for $i ( 0 .. 10 ) {
if ($i /2 = int ($i/2)) {
?>
<tr><td>Linha par </td></tr>
<? php
}
else {
?>
<tr><td>Linha impar </td></tr>
<?php
}
}
?>
</table>
</body>
</html>
veja usando esta técnica o desenhista consegue um visual +- 90% ao layout do resultado do script ele pode definir o desenho da tabela, styles, etc usando o dreamweaver ou kompozer por exemplo, com a template separada isto não é possivel, alem disso é muito complicado dar manutenção em script e template separados a produtividade cai muito ,
o PHP é excelente mas ou é mais lerdo ou eu não soube configurá-lo corretamente porque a velocidade dos scripts abaixou e o consumo de memória do servidor aumentou muito além disso eu teria que abrir mão de quase 10 anos de programação em CGI/perl, quando o pessoal acenou com a continuação do projetor perl no Perl6 ja orientado a objeto, eu preferi continuar em perl mesmo e utilizar a técnica acima descrita, o Ò do Borogodó seria criar minha própria DTD para permitir os
editores WYSIWYG reconhecerem a tag <?perl ?> talvez eu faça isso.
Blz Eustáquio, mas manter o código totalmente separado também não é solução, a soluçaõ mais próxima que eu encontrei foi o EmbPerl, mas veja quando voce usa as tags [+ +] o kompozer por exemplo não entende que deva ignorar o conteúdo dentro desta tag, veja um exemplo clássico voce precisa construir uma tabela com linhas de cores de fundo diferente, geralmente o Webdesigner não sabe nada de código se ele não estragar o código ja ajuda muito e o programador é igual ao windows 3.0 ou seja só encherga 16 cores , eu preciso integrar o serviço dos dois, no mercado eu so encontro desenhistas que produzem 90% de seus contúdos usando Dreamweaver, e programadores só em PHP quando encontro. vejamos o caso da tabela multicor
<html>
<body>
<table>
<tr><td>cabeçalho</td></tr>
<?php for $i ( 0 .. 10 ) {
if ($i /2 = int ($i/2)) {
?>
<tr><td>Linha par </td></tr>
<? php
}
else {
?>
<tr><td>Linha impar </td></tr>
<?php
}
}
?>
</table>
</body>
</html>
veja usando esta técnica o desenhista consegue um visual +- 90% ao layout do resultado do script ele pode definir o desenho da tabela, styles, etc usando o dreamweaver ou kompozer por exemplo, com a template separada isto não é possivel, alem disso é muito complicado dar manutenção em script e template separados a produtividade cai muito ,
o PHP é excelente mas ou é mais lerdo ou eu não soube configurá-lo corretamente porque a velocidade dos scripts abaixou e o consumo de memória do servidor aumentou muito além disso eu teria que abrir mão de quase 10 anos de programação em CGI/perl, quando o pessoal acenou com a continuação do projetor perl no Perl6 ja orientado a objeto, eu preferi continuar em perl mesmo e utilizar a técnica acima descrita, o Ò do Borogodó seria criar minha própria DTD para permitir os
editores WYSIWYG reconhecerem a tag <?perl ?> talvez eu faça isso.
[9] Comentário enviado por hugoeustaquio em 24/01/2008 - 19:42h
Normalmente os sistemas de template possuem uma sintaxe para estruturas de repetição (normalmente de forma parecida com o JSP), sem que isso polua o html, mantendo compatibilidade com os editores WYSIWYG. Não conheço os sistemas de template para perl, mas uso muito o django, e os templates dele abrem perfeitamente bem em todos os editores que já abri. Talvez esteja faltando algo assim no mercado que seja escrito em perl, mas talvez valha a pena você procurar testar os templates para perl. A sintaxe do Perl Template Toolkit usa as tags "[% %]", teste se elas entram em conflito com o Dreamweaver (dentro dos valores de parâmetro dos imputs, dentro das tabelas, etc...). Qualquer coisa poste o resultado aqui. Ah, a propósito, a produtividade sobe muito quando se usa sistema de template. Talvez você tenha essa sensação devido a curva de aprendizagem, que é um pouco íngreme, mas quando você domina as opções de marcação do sistema, a produtividade sobe muito, e a facilidade de manutenção também.
Normalmente os sistemas de template possuem uma sintaxe para estruturas de repetição (normalmente de forma parecida com o JSP), sem que isso polua o html, mantendo compatibilidade com os editores WYSIWYG. Não conheço os sistemas de template para perl, mas uso muito o django, e os templates dele abrem perfeitamente bem em todos os editores que já abri. Talvez esteja faltando algo assim no mercado que seja escrito em perl, mas talvez valha a pena você procurar testar os templates para perl. A sintaxe do Perl Template Toolkit usa as tags "[% %]", teste se elas entram em conflito com o Dreamweaver (dentro dos valores de parâmetro dos imputs, dentro das tabelas, etc...). Qualquer coisa poste o resultado aqui. Ah, a propósito, a produtividade sobe muito quando se usa sistema de template. Talvez você tenha essa sensação devido a curva de aprendizagem, que é um pouco íngreme, mas quando você domina as opções de marcação do sistema, a produtividade sobe muito, e a facilidade de manutenção também.
[10] Comentário enviado por arnaldoestevao em 25/01/2008 - 10:09h
não, as tags [+ +] e [% %] não são compatíveis com o DreamWeaver e poluem o html .
não, as tags [+ +] e [% %] não são compatíveis com o DreamWeaver e poluem o html .
[11] Comentário enviado por hugoeustaquio em 25/01/2008 - 11:13h
Ahá! Achei a solução definitiva para você! O Perl Template Toolkit pode mudar de tag de configuração. Veja no endereço http://template-toolkit.org/docs/manual/Config.html#section_TAG_STYLE
Assim você pode usar qualquer tag que não entre em conflito com o DreamWeaver, pode até usar a tag <?php ?>, mais eu te aconselho a usar a tag mais comum (creio que seja a mais usada por linguagens de marcação de template) que é <% %> e deve funcionar no Dreamweaver perfeitamente!
Ahá! Achei a solução definitiva para você! O Perl Template Toolkit pode mudar de tag de configuração. Veja no endereço http://template-toolkit.org/docs/manual/Config.html#section_TAG_STYLE
Assim você pode usar qualquer tag que não entre em conflito com o DreamWeaver, pode até usar a tag <?php ?>, mais eu te aconselho a usar a tag mais comum (creio que seja a mais usada por linguagens de marcação de template) que é <% %> e deve funcionar no Dreamweaver perfeitamente!
[12] Comentário enviado por arnaldoestevao em 25/01/2008 - 12:53h
O dreamweaver aceita as tags <% %> o kompozer não, ja a utlização de comentários que foi minha primeira opção da um xabú com o dreamweaver, é que ele usa -> ao invez de --> pra fechar comentários,
então quando voce usa uma expresão $recordset->getvalue(0,0) ele suja o código html. Além disto com esta técnica eu transfiro 99% do código pra dentro da template até agora a única coisa que o perl não aceitou foi anexar módulos externos em tempo de run time, no resto a função eval se comportou de forma identica ao próprio perl e eu tenho scripts rodando com mais de 100 linhas de código inclusive com declaração de subs, utilização de funções em módulos externos e declaração de váriaveis globais , e também quando ocorre um erro de run time durante o desenvolvimento, ao invez de receber a tela 500 do apache eu recebo a mensagem de erro que o script esta gerando , fica bem mais fácil depurar e tratar erros
outra vantagem para mim é poder usar
<a href="$link">
ao invéz de
<a href="[% $link %]">
eu acho o primeiro mais limpo
O dreamweaver aceita as tags <% %> o kompozer não, ja a utlização de comentários que foi minha primeira opção da um xabú com o dreamweaver, é que ele usa -> ao invez de --> pra fechar comentários,
então quando voce usa uma expresão $recordset->getvalue(0,0) ele suja o código html. Além disto com esta técnica eu transfiro 99% do código pra dentro da template até agora a única coisa que o perl não aceitou foi anexar módulos externos em tempo de run time, no resto a função eval se comportou de forma identica ao próprio perl e eu tenho scripts rodando com mais de 100 linhas de código inclusive com declaração de subs, utilização de funções em módulos externos e declaração de váriaveis globais , e também quando ocorre um erro de run time durante o desenvolvimento, ao invez de receber a tela 500 do apache eu recebo a mensagem de erro que o script esta gerando , fica bem mais fácil depurar e tratar erros
outra vantagem para mim é poder usar
<a href="$link">
ao invéz de
<a href="[% $link %]">
eu acho o primeiro mais limpo
[13] Comentário enviado por hugoeustaquio em 25/01/2008 - 14:08h
Não senhor! Não se coloca 99% dos códigos de controle para dentro do template, nunca!
Nunca se usa um código como "$recordset->getvalue(0,0)" num template, seu código tera que passar um valor que será usado no template. Os sistemas de template possuem estruturas de controle porque elas ajudam a construir a visualização, como no seu exemplo de cores (que não possui nada referente ao controle, somente visualização) mas que não devem ser utilizadas para o controle da aplicação. Você continuará a usar seus códigos (inclusive com declaração de subs e mais de 100 linhas de código) só que agora retirará dele tudo o que é referente a visualização, facilitando (e muito) a manutenção do seu sistema.
Para não visualizar a mensagem de erro genérica do apache, bastará colocar um parâmetro que liga a debugação, fazendo com que o mesmo exiba a saída de depuração do script, ao invés do referido erro. O parâmetro é o seguinte: ErrorLog /usr/local/apache/logs/error_log que deve ser colocado no httpd.conf do apache (algumas distros mudam o nome ou a localização desse arquivo, mas creio que a maioria das distros o colocam em /etc/httpd/httpd.conf ou /etc/apache/httpd.conf), assim voltará a ser tão fácil depurar seus script quanto era antes. Caso você utilize mod_perl, será mais fácil ainda, nem precisará ver os logs, ele tem uma diretiva de debugação, mas lembre-se de desligar esses mecanismos quando for configurar um servidor de produção. Quanto a última vantagem que você apontou, o código do template não seria o que você colocou, seria o seguinte:
<a href="<% link %>" />
sendo que o caractere "$" foi eliminado. Com todo o respeito, essa opção é evidentemente superior, só pelo fato de não conter caracteres que podem atrapalhar os editores. Quem se encarregará de setar o valor de "link" será o seu programa que faz uso do template. Por fim, teste todas as opções de mudança de tag do sistema de templates no komposer, com certeza alguma não causará conflito com ele. Provavelmente a sintaxe funcionará, teste o exemplo abaixo e por favor poste aqui se isso deu certo ou não:
<table>
...<tr><td>cabeçalho</td></tr>
...<!-- FOREACH i in lista -->
......<!-- if i%2 == 0 -->
.........<tr><td>Linha par </td></tr>
......<!-- END -->
......<!-- ELSE -->
.........<tr><td>Linha impar </td></tr>
......<!-- END -->
</table>
Eu optei por utilizar os templates no comentário, que deve ser previamente configurada, conforme link que eu já postei.
Por favor, substitua os pontos por espaços, eu os coloquei para que o código ficasse identado. Usei a operação "%" que já calcula o resto da divisão inteira. Creio que qualquer raio de editor possa trabalhar com esse código, afinal de contas os comandos serão reconhecidos como comentários para ele. Dá pra retirar alguns "<!--" e "-->", mas colocando cada comando em um bloco do template eu achei que ficou mais didático.
notas adicionais:
* o desempenho do php é lento, mas um acelerador de cache resolve o problema http://www.ducea.com/2006/10/30/php-accelerators/
* se o comportamento do Dreamweaver não puder ser alterado, você pode alterar a configuração do template da seguinte forma:
my $template = Template->new({
...START_TAG => quotemeta('<!--'),
...END_TAG => quotemeta('->'),
});
obs: Talvez o seu legado de aplicações funcionando com o seu sistema PHPerl seja grande demais para mudar assim, de uma hora para outra, mas quando for iniciar um novo sistema, considere a hipótese de separar o código de controle da visualização, eu te garanto que não se arrependerá. Utilize também um mapeador objeto-relacional e você já estará pronto para fazer um sistema MVC sem nenhuma dor de cabeça!
Não senhor! Não se coloca 99% dos códigos de controle para dentro do template, nunca!
Nunca se usa um código como "$recordset->getvalue(0,0)" num template, seu código tera que passar um valor que será usado no template. Os sistemas de template possuem estruturas de controle porque elas ajudam a construir a visualização, como no seu exemplo de cores (que não possui nada referente ao controle, somente visualização) mas que não devem ser utilizadas para o controle da aplicação. Você continuará a usar seus códigos (inclusive com declaração de subs e mais de 100 linhas de código) só que agora retirará dele tudo o que é referente a visualização, facilitando (e muito) a manutenção do seu sistema.
Para não visualizar a mensagem de erro genérica do apache, bastará colocar um parâmetro que liga a debugação, fazendo com que o mesmo exiba a saída de depuração do script, ao invés do referido erro. O parâmetro é o seguinte: ErrorLog /usr/local/apache/logs/error_log que deve ser colocado no httpd.conf do apache (algumas distros mudam o nome ou a localização desse arquivo, mas creio que a maioria das distros o colocam em /etc/httpd/httpd.conf ou /etc/apache/httpd.conf), assim voltará a ser tão fácil depurar seus script quanto era antes. Caso você utilize mod_perl, será mais fácil ainda, nem precisará ver os logs, ele tem uma diretiva de debugação, mas lembre-se de desligar esses mecanismos quando for configurar um servidor de produção. Quanto a última vantagem que você apontou, o código do template não seria o que você colocou, seria o seguinte:
<a href="<% link %>" />
sendo que o caractere "$" foi eliminado. Com todo o respeito, essa opção é evidentemente superior, só pelo fato de não conter caracteres que podem atrapalhar os editores. Quem se encarregará de setar o valor de "link" será o seu programa que faz uso do template. Por fim, teste todas as opções de mudança de tag do sistema de templates no komposer, com certeza alguma não causará conflito com ele. Provavelmente a sintaxe funcionará, teste o exemplo abaixo e por favor poste aqui se isso deu certo ou não:
<table>
...<tr><td>cabeçalho</td></tr>
...<!-- FOREACH i in lista -->
......<!-- if i%2 == 0 -->
.........<tr><td>Linha par </td></tr>
......<!-- END -->
......<!-- ELSE -->
.........<tr><td>Linha impar </td></tr>
......<!-- END -->
</table>
Eu optei por utilizar os templates no comentário, que deve ser previamente configurada, conforme link que eu já postei.
Por favor, substitua os pontos por espaços, eu os coloquei para que o código ficasse identado. Usei a operação "%" que já calcula o resto da divisão inteira. Creio que qualquer raio de editor possa trabalhar com esse código, afinal de contas os comandos serão reconhecidos como comentários para ele. Dá pra retirar alguns "<!--" e "-->", mas colocando cada comando em um bloco do template eu achei que ficou mais didático.
notas adicionais:
* o desempenho do php é lento, mas um acelerador de cache resolve o problema http://www.ducea.com/2006/10/30/php-accelerators/
* se o comportamento do Dreamweaver não puder ser alterado, você pode alterar a configuração do template da seguinte forma:
my $template = Template->new({
...START_TAG => quotemeta('<!--'),
...END_TAG => quotemeta('->'),
});
obs: Talvez o seu legado de aplicações funcionando com o seu sistema PHPerl seja grande demais para mudar assim, de uma hora para outra, mas quando for iniciar um novo sistema, considere a hipótese de separar o código de controle da visualização, eu te garanto que não se arrependerá. Utilize também um mapeador objeto-relacional e você já estará pronto para fazer um sistema MVC sem nenhuma dor de cabeça!
[14] Comentário enviado por mineirobr em 29/09/2010 - 02:51h
Legal cara, mas prefiro template.
Parabens pela criatividade.
Deus é o limite.
Legal cara, mas prefiro template.
Parabens pela criatividade.
Deus é o limite.
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Como renomear arquivos de letras maiúsculas para minúsculas
Imprimindo no formato livreto no Linux
Vim - incrementando números em substituição
Efeito "livro" em arquivos PDF
Como resolver o erro no CUPS: Unable to get list of printer drivers
Tópicos
É cada coisa que me aparece! - não é só 3% (3)
Melhorando a precisão de valores flutuantes em python[AJUDA] (5)
Top 10 do mês
-
Xerxes
1° lugar - 66.395 pts -
Fábio Berbert de Paula
2° lugar - 50.297 pts -
Buckminster
3° lugar - 17.921 pts -
Mauricio Ferrari
4° lugar - 15.612 pts -
Alberto Federman Neto.
5° lugar - 14.528 pts -
Diego Mendes Rodrigues
6° lugar - 13.225 pts -
Daniel Lara Souza
7° lugar - 12.761 pts -
edps
8° lugar - 11.290 pts -
Andre (pinduvoz)
9° lugar - 10.954 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 10.959 pts
Scripts
[Python] Automação de scan de vulnerabilidades
[Python] Script para analise de superficie de ataque
[Shell Script] Novo script para redimensionar, rotacionar, converter e espelhar arquivos de imagem
[Shell Script] Iniciador de DOOM (DSDA-DOOM, Doom Retro ou Woof!)
[Shell Script] Script para adicionar bordas às imagens de uma pasta
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
