shell-script-pt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [shell-script] Re: Enviar músicas para o MP4.


From: Fernando Mercês
Subject: Re: [shell-script] Re: Enviar músicas para o MP4.
Date: Tue, 29 Nov 2011 16:07:31 -0200

Salve, Rodrigo, tudo bem?

Vou dar uns pitacos:

1. Quando você repete muito código, é a hora de usar funções. Uma boa
aí seria definir, no início do script, uma função de erro, por
exemplo:

err() {
   zenity --info --title "Erro!" --text "$1"
   exit 1
}

Aí na hora de informar erro, basta fazer:

err "mensagem do erro"

2. Colocar todo o seu programa dentro de um bloco de if ou else não é
muito prático. Ao invés de fazer:
---
if [ ! -n "$1" ]; then
  #erro
else
  # todo seu programa
fi
---
Prefira:
---
if [ ! -n "$1" ]; then
  #erro
  exit 1
fi

#todo seu programa
---

Ou melhor, já usando a sugestão da função err():

---
test -f "$1" || err "Falta arquivo de entrada ou não existe..."

# todo o seu programa.
--

Como a função err() tem um exit, ao ser chamada, o script será
encerrado. Perceba também que usei a opção -f do teste já neste teste
do argumento, então você não precisaria testar novamente como faz na
linha 14. ;)

3. Você checa se o arquivo foi passado na linha de comando, mas dentro
do script você fixou o arquivo (linha 12), é isso mesmo? Se sua ideia
era fazer uma lógica do tipo "se o usuário informar um arquivo, usa,
do contrário, usa o padrão
/home/$USER/.enviarParaMP4-pontoDeMontagem", melhor fazer assim:

arquivo="$HOME/.enviarParaMP4-pontoDeMontagem"
test -f "$1" && arquivo=$1 || echo "Aviso: usando arquivo padrão $arquivo"

O que vem depois do && só é executado se o test retornar sucesso. O
que vem depois do || só é executado se o test falhar.

Acho que se você pensar nestes três itens e aplicar em todo o código,
terá um script muito menor. ;)

Grande abraço e boa sorte!

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
softwarelivre-rj.org
@MenteBinaria
------------------------------------
Participe do I Hack'n Rio
                 hacknrio.org
------------------------------------


2011/11/26 Rodrigo Boechat <address@hidden>
>
>
>
> Acho que finalizei o script.
> A nova nova nova versão está no pasteBin:
> http://pastebin.com/XMYX6bAR
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
>
> MrBits,
> Implementei a contagem de arquivos.
> Creio estar funcionando corretamente. hehe
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Alysson,
> Alterei conforme sua observação.
> Obrigado.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Pessoal,
>
> Enquanto eu estava fuçando no script esbarrei com uma curiosidade.
> Fiz o exemplo a baixo para demonstrar o que me aconteceu [Coloquei
> "underscore" no lugar de espaços dentro do echo por causa do formato html]:
>
> echo "campo/1_campo/2__campo/3___campo/4____campo/5" | sed -e
> "s/\([a-z0-9/]* *\)\{4\}[0-9a-zA-Z/ ]*/\1\##/"
>
> Sem querer, esse comando de SED que eu fiz, retornou exatamente:
> "campo/4____"
> !!!!!!
> Depois foi só adicionar na linha de sed o "; s/ *//g" e obtive:
> "campo/4"
>
> O interessante é que eu esperava que o retorno fosse o seguinte:
> "campo/1_campo/2__campo/3___campo/4____"
>
> Já que eu tive esse retorno inesperado da regex aproveitei e substituí
> uns AWK's, deixando umas linhas menores.
> Mas o fato é que eu fiquei sem entender o porque disso ter acontecido.
>
> Alguém consegue compreender o porque? Como eu faria para obter o retorno
> esperado?
> Já bati um bocado de cabeça e não cheguei na solução. Agora está mais
> como curiosidade que como necessidade, mesmo.
>
> Obrigado por toda a ajuda.
> :)
>
> <http://pastebin.com/XMYX6bAR>
>
> Em 17-11-2011 09:22, Alysson Gonçalves de Azevedo escreveu:
>
> > Vi que dentro do while, vc ta rodando o df a todo momento...
> > Eu sei que o df é rapinho... mas só por sugestão... não seria melhor pegar
> > o tamanho do dispositivo apenas 1 vez e depois subtrair do espaço livre o
> > tamanho de cada musica?
> >
> > Saudações...
> >
> > Alysson Gonçalves de Azevedo
> > (11) 8491-7730
> >
> >
> >
> > Em 17 de novembro de 2011 03:25, Rodrigo Boechat<
> > address@hidden> escreveu:
> >
> >> **
> >>
> >>
> >> Realmente interessante.
> >> Eu mesmo pensei em perguntar, mas o Tiago foi o fez na minha frente.
> >> :)
> >>
> >> Bem aqui segue a nova versão da bagaça:
> >> http://pastebin.com/XMYX6bAR
> >> Se alguém enxergar como melhorar qualquer coisa, me avisa!
> >>
> >> Tiago,
> >> Tentei implementar o esquema da verificação do tamanho do arquivo.
> >> Acredito estar funcionando. Mas ainda carece de testes.
> >>
> >> Como eu optei por verificar o tamanho do arquivo para reservar os 100KB,
> >> pros arquivos de configurações do aparelho, não mexi com o tratamento de
> >> erro sobre o cp.
> >>
> >> Ainda estou vendo uma maneira de limitar a quantidade de arquivos no
> >> diretório para 999, que é o que o aparelho suporta.
> >> Logo mando novas a respeito disso. Talvez um:
> >> ls | grep ".mp3" | wc -l
> >> resolva meu caso. Eu que não tive tempo de implementar ainda.
> >> - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
> >>
> >> MrBits,
> >> Obrigado pela ajuda e pela dica do /proc...
> >> Também pelo sed -e 's/^.*\[//g ; s/\].*$//g'
> >> Essa abordagem de separar o que eu realmente precisava ficou muito mais
> >> fácil e conveniente que meu:
> >>
> >> sed -e "s/^.\{28\}\([a-z]\{3\}\).*/\1/"
> >>
> >> E não consegui evitar os subshells, infelizmente.
> >> Quebrei cabeça, pesquisei e descobri que, para os processos necessários
> >> envolvidos, não há escapatória.
> >> Ou eu esqueci de alguma coisa?
> >> - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
> >>
> >> Julio,
> >> Obrigado pelas dicas. Também suas explicações foram esclarecedoras.
> >> - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
> >>
> >> Abraço a todos!
> >> Rodrigo Boechat
> >>
> >> Em 16-11-2011 14:53, Julio C. Neves escreveu:
> >>
> >>> Fala Pacman,
> >>> isso vem desde a época do UNIX. Suponha que vc faça um find assim:
> >>>
> >>> find . -name arq\? -exec grep -l palavra {} \;
> >>>
> >>> e supondo que esse find encontrasse arq1, arq2 e arq3, a linha montada
> >> pelo
> >>> exec para execução seria:
> >>> rm arq1 ; rm arq2 ; rm arq3
> >>>
> >>> Usando \+, esta linha ficaria:
> >>> rm arq1 arq2 rm arq3
> >>>
> >>> Daí ser muito mais rápido.
> >>> Abcs,
> >>> Julio
> >>> *Quer aprender tudo de Shell em 2 fins de semana?*
> >>> * address@hidden<address@hidden> ou (21) 8112-9988*
> >>> **
> >>> *** » **julioneves1 » juliobash*
> >>>
> >>>
> >>>
> >>> Em 16 de novembro de 2011 13:58, Tiago Peczenyj
> >>> <address@hidden>escreveu:
> >>>
> >>>> **
> >>>>
> >>>>
> >>>> puxa julio eu nao conhecia o \+
> >>>>
> >>>> vi rapidamente no man find, por acaso o seu livro aborda esta
> >>>> construção? confesso que para mim é novidade.
> >>>>
> >>>> 2011/11/16 Julio C. Neves<address@hidden>:
> >>>>> Só para otimizar I/O. Use o mesmo conceito no resto. Troque as linhas:
> >>>>> find "/proc/scsi/usb-storage/" -type f -exec grep -l
> >>>>> "$dispositivoSerial" {} \; | awk -F '/' '{print "sd "$5}' | tail -n1>
> >>>>> $dispositivoArquivo
> >>>>> read dispositivo< $dispositivoArquivo
> >>>>>
> >>>>> por:
> >>>>> read dispositivo<<< $(find /proc/scsi/usb-storage/ -type f -exec grep
> >>>>> -l "$dispositivoSerial"
> >>>>> {} \+ | awk -F '/' '{print "sd "$5}' | tail -n1)
> >>>>>
> >>>>> Será gerado um subshell para executar o find, mas será mais rápido por
> >>>> não
> >>>>> fazer I/O. Repare tb que troquei o \; do exec por \+ para ser mais
> >>>> rápido.
> >>>>> Abcs,
> >>>>> Julio
> >>>>> *Quer aprender tudo de Shell em 2 fins de semana?*
> >>>>> * address@hidden<address@hidden> ou (21) 8112-9988*
> >>>>> **
> >>>>> *** » **julioneves1 » juliobash*
> >>>>>
> >>>>>
> >>>>>
> >>>>> Em 15 de novembro de 2011 19:05, Rodrigo Boechat<
> >>>>> address@hidden> escreveu:
> >>>>>
> >>>>>> **
> >>>>>>
> >>>>>>
> >>>>>> Tiago,
> >>>>>>
> >>>>>> A sua ideia de abordagem para a questão do espaço foi interessante.
> >>>>>> Realmente esqueci que existe a saída de erro... T_T"
> >>>>>> O fato é que nunca mexi com isso. Vou pesquisar.
> >>>>>>
> >>>>>> Também suas observações foram bem feitas. O meu MP4 shing-ling suporta
> >>>>>> 999 MPtrêzes.
> >>>>>> Ok. Eu perguntaria como eu colocaria 999 músicas de qualidade "padrão"
> >>>>>> num espaço de 2GB... mas isso não vem ao caso.
> >>>>>> Hehehe
> >>>>>> E, novamente, sim. Estive olhando o MP4. Ele salva suas configurações
> >> de
> >>>>>> maneira confusa em vários arquivinhos de texto.
> >>>>>> Então seria interessante reservar uns 100KB para o próprio aparelho.
> >>>>>>
> >>>>>> Estudarei como implementar suas ideias em breve.
> >>>>>> Por enquanto, obrigado. Assim que eu tiver alguma novidade a esse
> >>>>>> respeito eu mostro || echo "Ou mando dúvidas".
> >>>>>>
> >>>>>> ----------------------------------------
> >>>>>> MrBits,
> >>>>>>
> >>>>>> Rapaz, eu fis muita pesquisa para saber como encontrar o raio do ponto
> >>>>>> de montagem.
> >>>>>> Nunca eu ia imaginar que esse caminho do proc/scsi pudesse existir. :)
> >>>>>> Porque em todas as explicações que eu achei, nada falou a respeito.
> >>>>>>
> >>>>>> Bom. Da forma abaixo, consegui fazer o processo sem usar subshell.
> >>>>>> Em contra partida, criou-se um tráfego maior de IO.
> >>>>>>
> >>>>>> dispositivoArquivo="/home/$USER/.enviarParaMP4-dispositivo"
> >>>>>>
> >>>>>> find "/proc/scsi/usb-storage/" -type f -exec grep -l
> >>>>>> "$dispositivoSerial" {} \; | awk -F '/' '{print "sd "$5}' | tail -n1>
> >>>>>> $dispositivoArquivo
> >>>>>>
> >>>>>> read dispositivo< $dispositivoArquivo
> >>>>>>
> >>>>>> dmesg | grep -e "$dispositivo.*\[.*Attached" | sed -e 's/^.*\[//g ;
> >>>>>> s/\].*$//g' | tail -n1> $dispositivoArquivo
> >>>>>>
> >>>>>> read dispositivo< $dispositivoArquivo
> >>>>>>
> >>>>>> mount | grep -i "$dispositivo" | awk '{print $3}'> $dispositivoArquivo
> >>>>>>
> >>>>>> read dispositivo< $dispositivoArquivo
> >>>>>>
> >>>>>> rm "$dispositivoArquivo"
> >>>>>>
> >>>>>> A questão, é: O que mais vale a pena?
> >>>>>> Voltando aos primórdios da época da faculdade, lembro que IO é sempre
> >>>>>> mais lento que processamento na memória.
> >>>>>> Mas como eu sou novo na área, realmente gostaria de saber se o caso é
> >>>>>> válido. Pois o shell trabalha "suave" com arquivos de texto. E seu eu
> >>>>>> jogasse esses arquivos para uma "tmpfs" ao invés do home?
> >>>>>>
> >>>>>> Grato pela ajuda,
> >>>>>> Rodrigo Boechat
> >>>>>>
> >>>>>> Em 15-11-2011 09:33, MrBiTs escreveu:
> >>>>>>
> >>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>>> Hash: SHA256
> >>>>>>>
> >>>>>>> On 11/15/2011 01:51 AM, Rodrigo Boechat wrote:
> >>>>>>>> MrBiTs, obrigado pela ajuda!
> >>>>>>>>
> >>>>>>>> Estou implementando, seguindo sua dica. O problema é que, olhando
> >>>>>>> meu script percebi que há muita subshell. Tentei, mas ainda
> >>>>>>>> não consegui enxergar uma maneira de evitá-las.
> >>>>>>>>
> >>>>>>>> Tentei usar o esquema:
> >>>>>>>>
> >>>>>>>> variavel=comandos ${variavel}
> >>>>>>>>
> >>>>>>>> Mas não deu certo. E vom o eval eu ainda continuo no problema de
> >>>>>>> subshell.
> >>>>>>>> Aqui o ${!variavel} sempre retorna vazio.
> >>>>>>>>
> >>>>>>>> Existe uma maneira de melhorar a coisa?
> >>>>>>> Quando eu tenho tarefas repetitivas de geração de dados, eu
> >> geralmente
> >>>>>>> as executo uma única vez, direcionando sua saída para uma
> >>>>>>> espécie de arquivo de configuração. Posso exemplificar isso numa
> >>>>>>> leitura de arquivos que contenham um dado de código de qualquer
> >>>>>>> coisa, cuja descrição está numa tabela de banco de dados. Ao invés de
> >>>>>>> ler a tabela para cada linha, eu a leio uma única vez e jogo
> >>>>>>> sua saída num arquivo no formato chave-valor. Como o bash 4 suporta
> >>>>>>> nativamete arrays associativos, via declare -A, fica fácil
> >>>>>>> você construir a relação. A versão 3 do bash não possui isso
> >>>>>>> nativamente, então o ideal é fazer upgrade. Eu particularmente acho
> >>>>>>> eval a praga do shell-script. Se é para usar eval e deixar o script
> >>>>>>> ininteligível, é mais fácil partir para outra linguagem.
> >>>>>>>
> >>>>>>> Não me parece, entretanto, ser o caminho, já que você vai querer
> >>>>>>> plugar seu emepêquatlo (outro dia me falaram em MP-6, porque
> >>>>>>> tocava música, filme, tirava fotos, mostrava fotos, tinha rádio AM-FM
> >>>>>>> e jogos, subvertendo a abreviação do formato mpeg layer 4,
> >>>>>>> usando isso para indicar quantas funções o aloz flito tinha) a
> >>>>>>> qualquer momento e ele poderá usar um dispositivo diferente. Se não
> >>>>>>> fosse assim, minha recomendação seria que você gerasse um arquivo de
> >>>>>>> parâmetros quando o computador iniciasse.
> >>>>>>>
> >>>>>>> Claro que usar subshell não é crime. Tudo são ferramentas. Numa hora,
> >>>>>>> uma subshell é ruim, como no caso que analisamos da
> >>>>>>> velocidade do script, mas tem horas que somente subshells vão
> >>>> resolver.
> >>>>>>> Um trecho que me chamou a atenção foi esse:
> >>>>>>>
> >>>>>>> dmesg | grep -i "$numeroDoDispositivo" | grep -i "$nome2MP4" | sed -e
> >>>>>>> "s/^.\{28\}\([a-z]\{3\}\).*/\1/" | tail -n1>"$dispositivo"
> >>>>>>> pontoDeMontagem=$(mount | grep -i "`cat /home/$USER/.dispositivo`" |
> >>>>>>> sed -e "s/^.\{12\}\([0-9a-zA-Z/ -]*\) type.*/\1/")
> >>>>>>>
> >>>>>>> Primeiro você gera uma string dados do dispositivo, só para filtrar o
> >>>>>>> mount com esse dado. Aí pensei em juntar tudo numa coisa só:
> >>>>>>>
> >>>>>>> pontoDeMontagem=$(mount | \
> >>>>>>> grep -i \
> >>>>>>> $(dmesg | \
> >>>>>>> grep -i "$numeroDoDispositivo" | \
> >>>>>>> grep -i "$nome2MP4" | \
> >>>>>>> sed -e "s/^.\{28\}\([a-z]\{3\}\).*/\1/" | \
> >>>>>>> tail -n1) | \
> >>>>>>> sed -e "s/^.\{12\}\([0-9a-zA-Z/ -]*\) type.*/\1/")
> >>>>>>>
> >>>>>>> Na minha opinião, ficou confuso demais e não reduz a quantidade de
> >>>>>>> subshells. Separei os comandos em linhas, para termos melhor
> >>>>>>> visibilidade.
> >>>>>>>
> >>>>>>> Linux tem algumas ferramentas legais para você analisar o que está
> >>>>>>> rodando ou instalado na sua máquina. Por exemplo, você procura
> >>>>>>> o número do dispositivo assim:
> >>>>>>>
> >>>>>>> numeroDoDispositivo=$(dmesg | grep -i "$nome1MP4" | sed -e
> >>>>>>> "s/^.\{20\}\([0-9:]\{8\}\).*/\1/" | tail -n1)
> >>>>>>>
> >>>>>>> Entretanto, você tem os sysfs e procfs que te ajudam muito. Veja que
> >>>>>>> legal:
> >>>>>>>
> >>>>>>> $ ls /proc/scsi/usb-storage
> >>>>>>> 6
> >>>>>>>
> >>>>>>> Esse 6 é exatamente o número do dispositivo USB que eu tenho plugado
> >>>>>>> no meu computador agora. Obviamente, ele por sí só não diz
> >>>>>>> muita coisa, mas se for o único arquivo do diretório, pronto, você já
> >>>>>>> eliminou um monte de subshell. Dentro do arquivo temos:
> >>>>>>>
> >>>>>>> Host scsi6: usb-storage
> >>>>>>> Vendor: Kingston
> >>>>>>> Product: DT 101 G2
> >>>>>>> Serial Number: 001CC07CEB39BB41891A0087
> >>>>>>> Protocol: Transparent SCSI
> >>>>>>> Transport: Bulk
> >>>>>>> Quirks:
> >>>>>>>
> >>>>>>> Então, talvez um find /proc/scsi/usb-storage -type f -exec grep -l
> >>>>>>> $nome1MP4 {}\; seja a forma de você achar o número do
> >>>>>>> dispositivo. O arquivo /proc/scsi/scsi também te dá informações
> >>>>>>> interessantes, mas ainda não me diz se ele está montado.
> >>>>>>>
> >>>>>>> Aí, para descobrir qual é o ponto de montagem do safado, e aí vamos
> >> ao
> >>>>>>> dmesg. Ele sempre escreve algo como sd #Device, então se eu
> >>>>>>> filtrá-lo por sd 6, devo ter algo legal:
> >>>>>>>
> >>>>>>> dmesg | grep -e "sd 6.*\[.*$nome2MP4"
> >>>>>>>
> >>>>>>> Ele vai me retornar alguma coisa assim:
> >>>>>>>
> >>>>>>> [57713.679823] sd 6:0:0:0: [sdb] Attached SCSI removable disk
> >>>>>>>
> >>>>>>> Aí, como o sdb é o que queremos, talvez um dmesg | grep -e "sd
> >>>>>>> 6.*\[.*Attached" | sed -e 's/^.*\[//g ; s/\].*$//g' seja legal.
> >>>>>>> Como sabemos que todo dispositivo USB será montado em um device
> >>>>>>> diferente, se plugarmos o primeiro, temos /dev/sdb, se plugarmos o
> >>>>>>> segundo, temos /dev/sdc, isso nos basta. Aí é só ver no mount
> >>>>>>>
> >>>>>>> mount | grep -i sdb
> >>>>>>>
> >>>>>>> E viva.
> >>>>>>>
> >>>>>>> Veja se diminui um pouco seus subshells.
> >>>>>>>
> >>>>>>> - --
> >>>>>>>
> >>>>>>> LLAP
> >>>>>>>
> >>>>>>> .0. MrBiTs - address@hidden<mailto:mrbits.dcf%40gmail.com>
> >>>>>>> ..0 GnuPG -
> >>>>>>>
> >> http://keyserver.fug.com.br:11371/pks/lookup?op=get&search=0x6EC818FC2B3CA5AB
> >>>>>>> <
> >> http://keyserver.fug.com.br:11371/pks/lookup?op=get&search=0x6EC818FC2B3CA5AB
> >>>>>>> 000 http://www.mrbits.com.br
> >>>>>>>
> >>>>>>> -----BEGIN PGP SIGNATURE-----
> >>>>>>> Version: GnuPG v1.4.11 (GNU/Linux)
> >>>>>>>
> >>>>>>> iQEcBAEBCAAGBQJOwk4AAAoJEG7IGPwrPKWr2TEH/ilB3vvv3mDQAuoHF2H3pgsB
> >>>>>>> zsfkOtZEeSExlnsOW35XgvHgB8h7wsIY7MeDaEoMAPY3PH+1eGzCEN9H8sopEpfG
> >>>>>>> D60TisBQOi4RkHJ2HvoHJPEo/Uxl3MGvyXQst2Ds50XmlmheMY6lj9+N0Fw8PQWP
> >>>>>>> /JZ/hL83s2FyoXLd2JtA7Bt9mPAbcEWeQuUcslhw+lzLc678P0rnmV9kAoDaSs9F
> >>>>>>> v9G/8dKELwsJ+DbweBUlJVYTnfSGkQBzegHdFA5OhJ8cC6DO7kiiXAZC+n0tJUQB
> >>>>>>> yhArU6iRFR3DPE1Acpe4SBrpbci7dwtP4JNNur+ScPE/fSoNtETsJU2Pz5E1Awk=
> >>>>>>> =3AEc
> >>>>>>> -----END PGP SIGNATURE-----
> >>>>>>>
> >>>>>>>
> >>>>>> [As partes desta mensagem que não continham texto foram removidas]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> [As partes desta mensagem que não continham texto foram removidas]
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------
> >>>>>
> >>>>> ----------------------------------------------------------
> >>>>> Esta lista não admite a abordagem de outras liguagens de programação,
> >>>> como perl, C etc. Quem insistir em não seguir esta regra será moderado
> >> sem
> >>>> prévio aviso.
> >>>>> ----------------------------------------------------------
> >>>>> Sair da lista: address@hidden
> >>>>> ----------------------------------------------------------
> >>>>> Esta lista é moderada de acordo com o previsto em
> >>>> http://www.listas-discussao.cjb.net
> >>>>> ----------------------------------------------------------
> >>>>> Servidor Newsgroup da lista: news.gmane.org
> >>>>> Grupo: gmane.org.user-groups.programming.shell.brazil
> >>>>>
> >>>>> Links do Yahoo! Grupos
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Tiago B. Peczenyj
> >>>> Linux User #405772
> >>>>
> >>>> http://pacman.blog.br
> >>>>
> >>>>
> >>> [As partes desta mensagem que não continham texto foram removidas]
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> ----------------------------------------------------------
> >>> Esta lista não admite a abordagem de outras liguagens de programação,
> >> como perl, C etc. Quem insistir em não seguir esta regra será moderado sem
> >> prévio aviso.
> >>> ----------------------------------------------------------
> >>> Sair da lista: address@hidden
> >>> ----------------------------------------------------------
> >>> Esta lista é moderada de acordo com o previsto em
> >> http://www.listas-discussao.cjb.net
> >>> ----------------------------------------------------------
> >>> Servidor Newsgroup da lista: news.gmane.org
> >>> Grupo: gmane.org.user-groups.programming.shell.brazil
> >>>
> >>> Links do Yahoo! Grupos
> >>>
> >>>
> >>>
> >> [As partes desta mensagem que não continham texto foram removidas]
> >>
> >>
> >>
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > ------------------------------------
> >
> > ----------------------------------------------------------
> > Esta lista não admite a abordagem de outras liguagens de programação, como 
> > perl, C etc. Quem insistir em não seguir esta regra será moderado sem 
> > prévio aviso.
> > ----------------------------------------------------------
> > Sair da lista: address@hidden
> > ----------------------------------------------------------
> > Esta lista é moderada de acordo com o previsto em 
> > http://www.listas-discussao.cjb.net
> > ----------------------------------------------------------
> > Servidor Newsgroup da lista: news.gmane.org
> > Grupo: gmane.org.user-groups.programming.shell.brazil
> >
> > Links do Yahoo! Grupos
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]