Eu tenho esse bash one-liner, ele roda bem no OSX, mas não no Linux, estou suspeitando que a distribuição Linux (Busybox) no meu Qnap tem algo a ver com isso.
Aqui está o comando que é executado no OSX:
find . -type f -name "*.mp4" -exec bash -c 'ffmpeg -i "$0" -c:v copy -c:a libfaac -af "volume=23dB" "fix/$0"' '{}' \;
Agora no Qnap:
find . -type f -name "*.mp4" -exec bash -c 'ffmpeg -i "$0" -c:v copy -c:a libfaac -af "volume=23dB" "fix/$0"' '{}' \;
retorna:
BusyBox v1.01 (2015.05.21-17:32+0000) multi-call binary
Usage: find [PATH...] [EXPRESSION]
Search for files in a directory hierarchy. The default PATH is the current directory; default EXPRESSION is '-print'
EXPRESSION may consist of: -follow Dereference symbolic links. -name PATTERN File name (leading directories removed) matches PATTERN. -print Print (default and assumed).
-type X Filetype matches X (where X is one of: f,d,l,b,c,...) -perm PERMS Permissions match any of (+NNN); all of (-NNN); or exactly (NNN) -mtime TIME Modified time is greater than (+N); less than (-N); or exactly (N) days
Como se o comando find não estivesse funcionando, então, se eu executar o comando find sozinho:
find . -type f -name "*.mp4"
funciona muito bem, eu recebo todos os meus arquivos, então suspeito que o problema é passar os arquivos para o comando exec , e é aí que eu não consigo descobrir
versão bash osx : GNU bash, versão 3.2.57 (1) -release (x86_64-apple-darwin14)
versão bash do linux : bash do GNU, versão 3.2.57 (1) -release (i686-pc-linux-gnu)
Eu suspeito que é baseado no posicionamento de consulta de posicionamento de aspas simples / duplas.
Geralmente, sempre uso algo assim em um arquivo de script (como conv.sh) para operações mais complexas:
find . -type f -name "*.mp4" | while read FILE
do
ffmpeg -i "$FILE" -c:v copy -c:a libfaac -af "volume=23dB" "fix/$FILE"
done
Agora, execute este arquivo com a depuração:
bash -xv ./conv.sh
Um script rápido e sujo que deve funcionar.