2015-12-06 4 views
0

Я пытаюсь получить тип звука в сценарии OSX sh, используя ffprobe: ffprobe "$i" |& egrep -ci "vorbis|aac" работает от cli в tcsh, но не из сценария. |&, похоже, не работает из внутреннего скрипта. |& перенаправляет вывод из ffprobe, иначе ffprobe распечатывает cli. Любая помощь приветствуется.pipe ffprobe in sh script

##mkv files 
for i in "$input"*.mkv ; do 
    if [ -e "$i" ] ; then 
     ##1st check type(vorbis|aac) 
     type=$(/usr/local/bin/ffprobe "$i" |& egrep -i "vorbis|aac") 
     echo "Test: $type" 
     ##just get audio format 
     type=$(/usr/bin/perl -e '[email protected][0];if (/(aac|vorbis)/ig) {print $1;}' "$type") 
     echo "Type: $type" 
     exit 
    fi 
done 

ошибки я получаю:

command substitution: line 46: syntax error near unexpected token `&' 
command substitution: line 46: `/usr/local/bin/ffprobe "$i" |& egrep -i "vorbis|aac"' 
+0

Почему вам нужно '| &' (я обычно не использую это, поэтому не помню, что это такое). Разве вы не можете просто «ffprobe» $ i »| grep -i ... '? Также ваш код выглядит как 'bash' или связанные с ним оболочки, а не tcsh. Например, 'tcsh' использует' endif', а не 'fi'. Удачи. – shellter

+0

Почему вы думаете, что это скрипт 'tcsh'? Это похоже на сценарий оболочки Bourne. '| &' не является стандартной конструкцией оболочки Bourne и работает только с 'bash' и, возможно, с некоторыми другими расширениями оболочки Bourne (и' csh' также имеет это). Этот скрипт должен работать нормально, если вы запустите его с помощью 'bash'. – Carpetsmoker

+0

Возможно, вам следует уточнить свой вопрос (отредактируйте текст и теги тоже!) И включите в него фактическое сообщение об ошибке; как есть, мы должны угадать слишком много вещей. – tripleee

ответ

0

Вы пытаетесь использовать tcsh синтаксис в sh сценария; тот факт, что это не работает, должно быть неудивительно, хотя вы, похоже, не знаете, что это два разных языка.

Пожалуй, самым простым немедленное решение для вашего скрипта, чтобы запустить его в bash вместо sh, где бывший поддерживает tcsh синтаксис, который вы пытались использовать, а не просто по совпадению, но потому, что он одолжил много хороших и некоторые менее хорошие идеи от tcsh, при сохранении полной обратной совместимости с POSIX sh.

Предполагая, что требуемая информация печатается на стандартный выход py ffprobe, вы также можете переключиться на обычную трубу и сохранить линию shebang sh. В любом случае, явно ссылаясь на сценарий с sh, рекомендуется меньше - просто отметьте файл как исполняемый и вызовите его напрямую, и система будет использовать любой интерпретатор, который указывает shebang (и, наоборот, shebang будет просто проигнорирован, если вы явно укажете переводчик).

Существует широкий консенсус, что tcsh следует избегать как для сценариев и интерактивного использования - Я бы посоветовал вам также рассмотреть переход на bash для интерактивного использования, который будет унифицировать синтаксис, по-видимому, уже использовать для сценариев с синтаксисом для интерактивного использования. Фактически, вы в настоящее время упускаете одну из привлекательных функций оболочки, используя несовместимую интерактивную оболочку.

csh.whynot Том Кристиансен является канонической ссылочной критикой оболочки С. В то время как tcsh исправляет большое количество ошибок и несоответствий от csh, многие все еще остаются. Переход на одну из доминирующих оболочек также даст вам более широкую сеть помощи, обучения и устранения неполадок для поддержки вас.

+0

Это почти правильный ответ, поэтому я мог бы также отметить его. В моей версии osx 'sh' вызывается' bash' в режиме posix. поэтому сценарий запускался из tcsh в bash. Мне просто пришлось сменить вызов 'ffprobe' на типичную переадресацию bash' type = \ '/ usr/local/bin/ffprobe '$ i" 2> & 1 | egrep -i "audio" \ '' – snjagr

+0

Тот факт, что 'sh' в вашей системе запускает Bash в режиме POSIX, является совпадением. Сценарии, отмеченные символом '#!/Bin/sh', должны (или, скорее, в основном должны) подчиняться ограниченному синтаксису, когда многие конструкции Bash недоступны. Во многих дистрибутивах на основе Debian по умолчанию 'sh' был изменен на' dash' ранее, чем символическая ссылка на Bash (например, на вашей системе), и это обнаружило много случаев, когда они были небрежны и/или где Bash должен был быть более строгий. Вы хотите избежать этого; будущие версии Bash просто могут быть более жесткими в том, какие багизмы они разрешают в режиме POSIX. – tripleee

+0

Если вы нашли этот ответ полезным, пожалуйста, примите его, щелкнув полый флажок рядом с большим количеством баллов, чтобы он стал сплошным зеленым. Это наделяет меня некоторыми точками репутации, но что более важно, отмечает ваш вопрос, чтобы он больше не возникал как неразрешенный. – tripleee

 Смежные вопросы

  • Нет связанных вопросов^_^