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, 02 Feb 2012 22:11:48 -0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111224 Thunderbird/9.0.1

Olá, boa noite.

Alguém poderia me ajudar?
Quando configurei essa nova versão no Thunar, percebi que havia erro na 
linha 76 do script:
http://pastebin.com/DLKipbzv

done <<< $(echo "$*" | sed -e "s/ \//\n\//g" | grep ".mp3")

Essa linha está mandando para a variável mp3 [linha 40] toda a lista de 
arquivos em uma linha apenas.
Quando aideia é separar os caminhos dos arquivos em linhas para o while 
trabalhar.

Estranho é que, criando um arquivo com a lista, usando a mesma linha:
echo "$*" | sed -e "s/ \//\n\//g" | grep ".mp3" > listaDeTeste

E jogando para o while o arquivo:
done < listaDeTeste

Funciona tudo corretamente.

Não consegui entender porque o erro acontece.
Tentei mas não consegui solucionar o erro.

Grato!

Em 24-01-2012 14:30, Rodrigo Boechat escreveu:
> Fernando,
> Bom dia.
>
> Obrigado pela sua colaboração.
> Suas observações foram interessantes e me ajudou muito a mudar meu 
> pensamento.
> Como iniciante no shellscript eu realmente não teria como adquirir o 
> conhecimento de toda a sintaxe da linguagem.
>
> Valeu muito suas dicas. Pensarei diferente de agora em diante. :)
>
> Segue a nova versão: http://pastebin.com/DLKipbzv
>
> Notei que a versão anterior tinha um erro feio na minha lógica, tinha 
> um "w" perdidão no meio do código que estava gerando outro erro [linha 
> 58 da versão anterior] e tive problemas com o ls [linha 56, versão 
> anterior].
> Acho que consegui resolver tudo. :)
>
> E só explicando. Minhas férias acabaram. Por isso demorei a responder.
>
> Abaixo eu coloquei uns comentários sobre o que você escreveu.
>
>
> Em 29-11-2011 16:07, Fernando Mercês escreveu:
>>
>> 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. ;)
>>
>
> A linha 14 testa outro arquivo que não é o mesmo do argumento de entrada.
> É um arquivo que "guarda" o ultimo device usado pelo MP4.
> Foi uma tentativa de tentar evitar que a cada execução o script 
> procurasse o aparelho novamente; assim ganharia performance. No 
> entanto, esbarrei em um erro. De curiosidade fui inserindo e removendo 
> pendrives junto com o MP4 até que um pendrive pegasse o mesmo 
> dispositivo já usado anteriormente pelo MP4. Aí os arquivos foram 
> copiado no pendrive, não para o MP4.
> Pela minha lógica, eu sabia que isso poderia acontecer. só forcei a 
> situação para obter a comprovação.
>
> Por esse motivo removi essa parte e voltei a fazer com que o script 
> procure, em cada execução, o ponto de montagem do MP4.
>
>>
>> 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. ;)
>>
>
> Bom, justamente a explicação anterior fala sobre o arquivo 
> ".enviarParaMP4-pontoDeMontagem".
> O caso da linha 14.
>
> Eu queria evitar a execução de parte do código se o MP4 já estivesse 
> montado. Mas como disse houve o erro já explicado.
> Até agora eu não consegui enxergar uma maneira de fazer isso, evitando 
> o possível problema, pois para evitar o problema o eu teria que fazer 
> toda a checagem novamente. O que tornaria o código redundante.
> Para que eu evitar de executar um código, sendo que para evitar erros 
> eu tenho que executá-lo? ^_^"
>
> Opa, me ocorreu uma ideia. Acho que posso verificar o serial direto 
> pelo ponto de montagem. Se for possível até valeria a pena executar 
> uma linha para verificar se o ponto de montagem se refere ao mesmo 
> serial contido na variável "$dispositivoSerial".
>
> *** É pesquisei um bocado. Não consegui encontrar nada que pudesse 
> fazer isso sem fazer os passos já feitos para conseguir o ponto de 
> montagem. Se alguém souber como se faz e puder contribuir, agradeço.
> :)
>
>>
>> Grande abraço e boa sorte!
>>
>
> Obrigado. O script final realmente ficou muito menor e mais limpo.
> Gostei do resultado.
>
> Quem tiver o Thunar ou a paciência de executá-lo na linha de comando, 
> por favor me retornem os resultados. Até agora não encontrei erros.
>
> Obrigado lista pelas ajudas!
> E se tiverem mais ideias para melhorar o script ou incrementar, me avisem!
>
> Rodrigo Boechat
>>
>>
>> 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 
>> <mailto:rodrigo.boechat.tenorio%40gmail.com>>
>> >
>> >
>> >
>> > 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 
>> <mailto:rodrigo.boechat.tenorio%40gmail.com>> 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 
>> <mailto:julio.neves%40gmail.com><address@hidden 
>> <mailto:julio.neves%40gmail.com>> ou (21) 8112-9988*
>> > >>> **
>> > >>> *** » **julioneves1 » juliobash*
>> > >>>
>> > >>>
>> > >>>
>> > >>> Em 16 de novembro de 2011 13:58, Tiago Peczenyj
>> > >>> <address@hidden 
>> <mailto:tiago.peczenyj%40gmail.com>>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 
>> <mailto:julio.neves%40gmail.com>>:
>> > >>>>> 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 
>> <mailto:julio.neves%40gmail.com><address@hidden 
>> <mailto:julio.neves%40gmail.com>> ou (21) 8112-9988*
>> > >>>>> **
>> > >>>>> *** » **julioneves1 » juliobash*
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> Em 15 de novembro de 2011 19:05, Rodrigo Boechat<
>> > >>>>> address@hidden 
>> <mailto:rodrigo.boechat.tenorio%40gmail.com>> 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><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>
>> > >>>>>>> <
>> > >> 
>> 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 
>> <mailto:shell-script-unsubscribe%40yahoogrupos.com.br>
>> > >>>>> ----------------------------------------------------------
>> > >>>>> 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 
>> <mailto:shell-script-unsubscribe%40yahoogrupos.com.br>
>> > >>> ----------------------------------------------------------
>> > >>> 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 
>> <mailto:shell-script-unsubscribe%40yahoogrupos.com.br>
>> > > ----------------------------------------------------------
>> > > 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]