Синтаксис ()
в сценариях sh
позволяет запускать подоболочку . Вы можете думать о подоболочках, как если бы следующие две строки были одинаковыми:
(echo foo)
sh -c "echo foo"
то есть внутри вашего сценария оболочки есть второй процесс, который обрабатывает все, что находится между ()
. Посредством символа вертикальной черты (« |
») стандартный вывод этой подоболочки соединяется со стандартным входом zenity.
Если вы щелкнете по кнопке «отменить» в окне zenity, это приведет к немедленному выходу из zenity. В этот момент стандартный вывод подоболочки становится недействительным. Это не сразу убивает подоболочку; однако, когда следующая команда echo
в этой подоболочке хочет выполнить запись в стандартный вывод, она получит сигнал SIGPIPE
, означающий, что канал, в который она пытается писать, не имеет считывателей. Стандартным поведением процесса при SIGPIPE
является завершение.
Вы заметите, что если вы запустите свой сценарий из терминала и нажмете кнопку «отменить» только после обновления, отправленного в zenity, приглашение оболочки не вернется сразу; поскольку команда сна все еще выполняется, и поскольку сон не производит вывода, требуется некоторое время, прежде чем будет произведен какой-либо вывод, и будет выдан SIGPIPE
.
Если вы не хотите такого поведения, вы должны указать оболочке не завершать работу после получения SIGPIPE:
#!/bin/sh
(
trap -- '' PIPE
echo "10"; sleep 1
# ... etc, your normal script goes here
) |
zenity --progress ...
Эта версия игнорирует SIGPIPE
и успешно продолжит работу после выхода из zenity.Однако учтите, что в этом случае кнопка «отмена» будет очень запутанной для пользователя; это вызовет выход из zenity, но не вызовет прерывание операции. Возможно, лучше было бы просто передать - без отмены
.
Первым шагом будет запуск каждого образа Docker в его собственном сетевом пространстве имен, а затем заполнение каждого из них виртуальными интерфейсами; возможно, в идеале один интерфейс для (ненарушенной )"локальной сети" и другой интерфейс для (нарушенной )"глобальной сети".
Каждый локальный сетевой интерфейс будет «подключен» к своему собственному интерфейсу в глобальных пространствах имен, а затем все они будут добавлены к мосту. Эта установка обеспечит локальную сетевую «кабельную связь».Затем вам может понадобиться добавить службу DHCP в эту сеть или иным образом использовать статические назначения.
Каждый интерфейс WAN также будет подключен к своему собственному интерфейсу в глобальном пространстве имен, и все они также будут добавлены к другому мосту, представляющему кабельную разводку для «WAN». Этот мост также будет иметь IP-адрес основного хоста, чтобы смоделированный трафик глобальной сети мог уйти в «настоящую» глобальную сеть. Для этого вы должны настроить правила iptables для направления трафика и вызвать нарушение, изменив эти правила.
Если вы хотите, чтобы возмущения применялись по-разному для разных докеров, вы, возможно, не стали бы объединять их в мост, а вместо этого вам нужно было бы иметь отдельные правила направления и манипулировать ими для отдельных возмущений. Или, в качестве альтернативы, вы подключаете их к мосту и вместо этого управляете их виртуальными кабелями (, которые соединяют каждый с соответствующим интерфейсом в пространстве имен )
.