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: 26.586 ]
Por: Arnaldo Luiz Estevao em 22/01/2008
helloworld.perl.php (2º exemplo)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Teste de $ENV{SCRIPT_NAME}</title>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
</head>
<body>
<?php perl $seunome=param('seunome'); print endperl ?>
Construção de um form e de uma tabela
<form>
Seu nome <input name="seunome" value="$seunome">
<input type="submit" name="enviar" value="Enviar">
</form>
<table border=1>
<?php perl for ($i; $i < 20 ; $i ++) { print endperl ?>
<tr>
<td>$i</td>
</tr>
<?php perl } print endperl ?>
<br>
</body>
</html>
<head>
<title>Teste de $ENV{SCRIPT_NAME}</title>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
</head>
<body>
<?php perl $seunome=param('seunome'); print endperl ?>
Construção de um form e de uma tabela
<form>
Seu nome <input name="seunome" value="$seunome">
<input type="submit" name="enviar" value="Enviar">
</form>
<table border=1>
<?php perl for ($i; $i < 20 ; $i ++) { print endperl ?>
<tr>
<td>$i</td>
</tr>
<?php perl } print endperl ?>
<br>
</body>
</html>
Link para uma demo do 2º exemplo:
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
Instalando Slackware 11.0 em um pendrive
Autenticação mútua SSL em servidores de NF-e e CT-e
XML de NF-e ou CT-e ou MDF-e - Como validar usando os pacotes de esquemas do Governo
Leitura recomendada
Catalyst Framework Perl - Parte III
Catalyst Framework Perl - (parte 2)
Executando os principais frameworks Perl no cPanel com CGI
Catalyst Framework Perl (parte 1)
Twittando com o 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
Melhorando o tempo de boot do Fedora e outras distribuições
Como instalar as extensões Dash To Dock e Hide Top Bar no Gnome 45/46
E a guerra contra bots continua
Tradução do artigo do filósofo Gottfried Wilhelm Leibniz sobre o sistema binário
Conheça o firewall OpenGFW, uma implementação do (Great Firewall of China).
Dicas
Instalando o FreeOffice no LMDE 6
Anki: Remover Tags de Estilo HTML de Todas as Cartas
Colocando uma opção de redimensionamento de imagem no menu de contexto do KDE
Tópicos
Distribuição leve para iniciantes (5)
Resolução 2056x1080 no Debian (23)
Top 10 do mês
-
Xerxes
1° lugar - 67.208 pts -
Fábio Berbert de Paula
2° lugar - 55.847 pts -
Clodoaldo Santos
3° lugar - 41.396 pts -
Buckminster
4° lugar - 21.911 pts -
Sidnei Serra
5° lugar - 20.838 pts -
Alberto Federman Neto.
6° lugar - 16.694 pts -
Mauricio Ferrari
7° lugar - 16.610 pts -
Daniel Lara Souza
8° lugar - 16.546 pts -
Diego Mendes Rodrigues
9° lugar - 15.325 pts -
edps
10° lugar - 13.497 pts
Scripts
[Shell Script] Script para criar certificados de forma automatizada no OpenVpn
[Shell Script] Conversor de vídeo com opção de legenda
[C/C++] BRT - Bulk Renaming Tool
[Shell Script] Criação de Usuarios , Grupo e instalação do servidor de arquivos samba
[Shell Script] Tire screenshots com Scrot facilmente com Zscrot
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:
