Поскольку Вы не упоминали это, я предполагаю, что Вы находитесь на CentOS 5.
Старая версия rtorrent может быть найдена в репозитории EPEL. Я искал пакет здесь и нашел rtorrent версию 0.7.8. Число текущей версии 0.8.7. Проект Fedora имеет инструкции относительно установки репозитория EPEL здесь.
Если Вы захотите последнюю версию, то необходимо будет скомпилировать ее из источника с их веб-сайта.
Сценарий не начинается со строки хижины, таким образом, система выполняет его с /bin/sh
. На Ubuntu, /bin/sh
тире, оболочка, разработанная для быстрого запуска и выполнения только со стандартными функциями. Когда тире достигает строки 68, это видит синтаксическую ошибку: та круглая скобка ничего не значит для него в контексте.
Так как тире (как все другие оболочки) является интерпретатором, он не будет жаловаться, пока выполнение не достигнет проблематичной строки. Таким образом, даже если бы сценарий, успешно запущенный в какой-то момент в Вашем тестировании, это прервалось бы, после того как строка 68 была достигнута.
Строка хижины должна быть самой первой вещью в файле. Так как Вы используете функции удара, первая строка файла должна быть #!/bin/bash
или #!/usr/bin/env bash
.
Если хижина не будет на первой строке, то ее не будут уважать, независимо от оболочки пользователя root, SHELL
переменная или -s
флаг. Можно легко подтвердить, что это с простым примером:
#
#!/bin/bash
offfset=(`ls`)
echo $offset
Запущение этого скрипта с sudo повысит синтаксическую ошибку в последних версиях Ubuntu и Debian.
У Вас есть две опции удостовериться, что сценарий интерпретируется bash
:
Переместите хижину в первую строку
Выполненный sudo
как это:
sudo bash ./pi_dev_env_install.sh
Попробуйте DOS2UNIX в файле сценария. Иногда в источнике есть некоторые скрытые персонажи.
Команда:
dos2unix script_file.sh script_file.sh
sudo chmod 755 <script>
В моем случае ошибка заключалась в отсутствии прав на выполнение файла. Сообщение об ошибке появилось только тогда, когда я разделил команды:
$ sudo sh
# ./install
Для меня запуск скрипта с:
bash./< script file >
работает нормально.
Это может произойти, если вы переопределяете предполагаемый интерпретатор. Например, это будет работать с sh независимо от того, какой hash bang используется (удобно, когда не используется hash bang):
> sh run.sh
ИЛИ для запуска bash:
> bash run.sh
Чтобы разрешить ему использовать определенное в сценарии значение hash bang, используйте это:
>./run.sh
Проверьте, содержит ли путь к файлу или рабочему каталогу открывающую скобку '(' или пробел в нем, если есть, удалите скобки или пробелы.
sonarqube.sh
на Ubuntu 15.10. Измененный заголовок, как сказано. Выполнениеsudo sh ./sonar.sh console
. Все еще получение ошибки. – soufrk 01.09.2016, 09:58sonarqube.sh
илиsonar.sh
? Решиться. И так или иначе, если Вы не можете решить проблему с информацией в этом потоке, задают новый вопрос с полным содержанием сценария и вставки копии полное сообщение (сообщения) об ошибке. – Gilles 'SO- stop being evil' 01.09.2016, 10:06#! /bin/sh
выполняемый отлично. Теперь, это оставляет меня озадаченным. – soufrk 01.09.2016, 10:07