Silenciosamente matar subshell?

Observação:

• wait $subshellnão funcionará, pois $subshellnão é filho do processo waitem que você está executando. De qualquer forma, você não esperaria o processo fazer waitisso, então não importa muito.
• kill $subshellvai matar o subshell, mas não sleepse o subshell conseguiu iniciá-lo no momento da killexecução. No entanto, você pode executar sleepo mesmo processo comexec
• você pode usar SIGPIPE em vez de SIGTERM para evitar a mensagem
• deixar uma variável sem aspas em contextos de lista tem um significado muito especial em bash.

Então, tendo dito tudo isso, você pode fazer:

(
  subshell=$BASHPID
  kill -s PIPE "$subshell" &
  sleep 600
)
echo subshell done

(substitua sleep 60por exec sleep 60se quiser killmatar sleepe não apenas o subshell, que neste caso pode nem ter tempo de ser executado sleepno momento em que você o matar).

De qualquer forma, não tenho certeza do que você deseja alcançar com isso.

sleep 600 &

seria uma maneira mais confiável de iniciar sleepem segundo plano se fosse isso que você queria fazer (ou (sleep 600 &)se quisesse ocultar esse sleepprocesso do shell principal)

Agora com o seu real

sudo stdbuf -o0 wpa_supplicant -Dwext -i"$wifi" -c/etc/wpa_supplicant/wpa_supplicant.conf

comando, observe que sudogera um processo filho para executar o comando (apenas porque pode ser necessário registrar seu status ou executar algumas tarefas de sessão PAM posteriormente). stdbufno entanto, executará wpa_supplicantno mesmo processo, portanto, no final, você terá três processos (além do restante do script) na wpa_supplicantancestralidade de:

1. o subshell
2. sudo como filho de 1
3. wpa_supplicant (que estava executando stdbuf anteriormente) como filho de 2

Se você matar 1, isso não mata 2 automaticamente. Se você matar 2, no entanto, a menos que seja com um sinal como SIGKILL que não pode ser interceptado, isso matará 3 como sudoacontece ao encaminhar os sinais que recebe para o comando que executa .

De qualquer forma, esse não é o subshell que você gostaria de matar aqui, são 3 ou pelo menos 2.

Agora, se estiver executando como roote o restante do script não, você não poderá eliminá-lo tão facilmente.

Você precisaria que o killfosse feito como root, então você precisaria:

sudo WIFI="$wifi" bash -c '
  (echo "$BASHPID" &&
   exec stdbuf -o0 wpa_supplicant -Dwext -i"$WIFI" -c/etc/wpa_supplicant/wpa_supplicant.conf 2>&1
  ) | {
    read pid &&
      grep -m1 "pre-shared key may be incorrect" &&
      kill -s PIPE "$pid"
  }'

Dessa forma, wpa_supplicantestará rodando no mesmo $BASHPIDprocesso que o subshell que estamos fazendo com exec.

Pegamos o pid pelo pipe e rodamos killcomo root.

Observe que, se você estiver pronto para esperar um pouco mais,

sudo stdbuf -o0 wpa_supplicant -Dwext -i"$wifi" -c/etc/wpa_supplicant/wpa_supplicant.conf 2>&1 |
  grep -m1 "pre-shared key may be incorrect"

Teria wpa_supplicantmatado automaticamente com um SIGPIPE (pelo sistema, portanto, sem problema de permissão) na próxima vez que gravar algo naquele canal depois que grepele se for.

Algumas implementações de shell não esperariam pelo retorno de sudodepois grep(deixando-o rodando em segundo plano até obter SIGPIPEd), e com bash, você também pode fazer isso usando a grep ... <(sudo ...)sintaxe, onde bashnão espera por sudonenhum dos dois retornos grep.

Mais em Grep lento para sair depois de encontrar correspondência?

Subshell refere-se a um comando shell que é filho de algum shell, como filho do bash -ishell de login interativo que oferece um $prompt. Você não precisa executar seu comando em um subshell - você pode optar por executá-lo como um processo independente. Parece que isso pode ser apropriado porque você não quer que seu stdout / stderr atrapalhe a aparência de sua barra de progresso e porque você não quer que o shell pai relate ou mesmo perceba a morte de seu filho.

Existem ferramentas padrão para realizar isso, como daemonize e nohup. (Consulte também as páginas de manual .) Você pode se sair melhor com nohup . Aqui está um exemplo de como usá-lo para executar um programa trivial, que não cria nohup.out:

$ nohup true 2>&1 > /dev/null &

Faça com que seu programa, ou um script wrapper para seu programa, registre seu PID em /tmp/my.pid -- o bash disponibiliza isso como $$variável. Então o processo de monitoramento com a barra de progresso pode

$ kill `cat /tmp/my.pid`

quando não precisar mais desse programa para fazer mais processamento. Alternativamente, você pode preferir dar o nome do seu programa para killall.

Você pode estar procurando por isso

#!/bin/bash
(subshell=$BASHPID
  (kill $subshell & wait $subshell 2>/dev/null) &
sleep 600) &
wait $! 2>/dev/null

echo subshell done

aqui o subshell é colocado em segundo plano, então o shell pai espera, mas com a saída de espera enviada para /dev/null. Isso captura a Terminatedmensagem.

Observe que, se você alterar a espera para capturar a saída para o arquivo, por exemplo wait $! 2>wait_output, verá

 ./foo.sh: line 5:  1939 Terminated              ( subshell=$BASHPID; ( kill $subshell & wait $subshell 2> /dev/null ) & sleep 600 )

mostrando que Terminatedé do shell pai.

Uma pequena verificação para ver se funciona se houver alguma atividade antes de matar é

#!/bin/bash
(subshell=$BASHPID
 (sleep 1; kill $subshell & wait $subshell 2>/dev/null) &
sleep 600) & wait 2>wait_output

echo subshell done

Este exemplo fará uma pausa por um segundo antes de imprimir subshell done. Este exemplo também mostra como colocar em segundo plano e esperar tudo na mesma linha, por exemplo & wait 2>wait_output. Não tenho certeza se isso tem alguma vantagem/desvantagem sobre o exemplo com wait $!.

O principal a observar aqui é que as Terminatedmensagens vêm do controle de trabalho do shell pai de nível superior. Isso é o que vê o subshell terminar e gera a mensagem. Então é aí que você deseja capturar a saída. Redirecionar a waitsaída do comando faz isso.