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: Rodrigo Boechat
Subject: Re: [shell-script] Re: Enviar músicas para o MP4.
Date: Thu, 17 Nov 2011 03:25:41 -0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1

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]



reply via email to

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