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

[Rodrigo Boechat]

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]