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: Alysson Gonçalves de Azevedo
Subject: Re: [shell-script] Re: Enviar músicas para o MP4.
Date: Thu, 17 Nov 2011 09:22:39 -0200

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]



reply via email to

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