Смущенный, почему скрипт не выходит
Вот несколько вариантов:
Точное исправление:
коснитесь / etc / default / openmediavaultи повторите попытку. Возможно, вам потребуется исправить другие проблемы.Взломайте его с орбиты:
rm /var/lib/dpkg/info/openmediavault-omvextrasorg.postrm
Я обнаружил, что существует множество сценариев pre / post .deb, которые написаны с предположениями, которые могут не будь настоящим. Мне больше всего нравится сценарий prerm, который предполагает, что демон все еще работает, и вызывает сбой apt-get, когда это не так.
Редактировать: Глядя на https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-omvextrasorg/blob/master/debian/postrm Я предполагаю, что (1) не удастся. Используя (2), вам может потребоваться выполнить следующие команды:
/bin/rm -f /etc/apt/preferences.d/99omv-extras-org*
/bin/rm -f /etc/apt/sources.list.d/omv-extras-org-*.list
Насколько я могу судить, ваш сценарий действительно вышел; просто подстановка процесса завершилась и печаталась в фоновом режиме после того, как внешняя оболочка напечатала свое приглашение.
Чтобы избежать этого, можно было бы просто передать вашу функцию вместо использования> >(...):
( echo; echo; echo 'du results:'; exit 0 ) | handle_json foo
Это работает, потому что при записи cmd1 | cmd2две команды запускаются параллельно, при этом стандартный вывод cmd1подключен к стандартному вводу cmd2, и bash ожидает обе команды. завершить, чтобы считать конвейер завершенным.
Напротив, cmd1 > >(cmd2)делает почти то же самое, за исключением того, что bash не ждет завершения cmd2, прежде чем продолжить дальнейшие команды (в этом случае, печатая «масштабирование» и затем выходя,позволяя интерактивному bash напечатать свое приглашение ):, если случайно cmd2занимает значительно больше времени, чем cmd1, тогда происходит неожиданное состояние гонки, которое вы наблюдали.