Esci dalle sequenze nell'output dello script chiamato dall'applicazione ncurses

Attualmente sto eseguendo mcabber come mio client Jabber (che utilizza ncurses) in una sessione tmux sul mio homeserver. A livello locale eseguo iTerm2 come emulatore di terminale, che supporta l'attivazione di notifiche ringhio attraverso sequenze di escape di caratteri.

Nota: tutto echoin questa domanda funziona come printf %b, o echo -ein bash e GNU echo.

ad esempio echo "\e]9;foobar\007", iTerm2 invia un messaggio Growl con il testo "foobar".

Tuttavia, durante una sessione di tmux, le sequenze di escape vengono divorate. Pertanto, è possibile utilizzare la sequenza di escape dei caratteri proprietari in \Ptmuxquesto modo:

echo "\ePtmux;\e\e]9;foobar\007\e\\"

Ciò innesca un messaggio ringhio all'interno di una sessione di tmux.

Tuttavia, quando lo uso nel mio script di eventi di mcabber che viene generato quando viene ricevuto un nuovo messaggio, nessuna notifica viene attivata, come se l'eco fosse inviata al terminale sbagliato.

Suppongo che ciò abbia a che fare con quel mcabber che attiva lo script è un'applicazione ncurses, quindi l'output del mio normale script bash si perde e iTerm 2 non lo vede mai.

Ho anche provato a chiamare smcup senza successo prima di fare eco ad alcune idee che ho scoperto

tput smcup
echo "\ePtmux;\e\e]9;$FROM: $MSG\007\e\\"
tput rmcup

Suppongo che questo non funzioni in quanto il problema non sta tornando alla "finestra del terminale reale", ma più orientando l'output nella finestra di ncurses.

Qualche idea su questo?

Il motivo per cui uno script di eventi non riesce a inviare un messaggio "growler" è che mcabberchiude i flussi di input, output ed errore standard quando esegue un comando di evento. Puoi vederlo in hooks.c:

  if ((pid=fork()) == -1) {
    scr_LogPrint(LPRINT_LOGNORM, "Fork error, cannot launch external command.");
    g_free(datafname);
    return;   
  }    
  if (pid == 0) { // child
    // Close standard file descriptors
    close(STDIN_FILENO);
    close(STDOUT_FILENO);
    close(STDERR_FILENO);
    if (execl(extcmd, extcmd, arg_type, arg_info, bjid, arg_data,
              (char *)NULL) == -1) {
      // scr_LogPrint(LPRINT_LOGNORM, "Cannot execute external command.");
      exit(1);
    }
  }
  g_free(datafname);

Ciò rende lo script dell'evento eseguito senza interferire con i flussi utilizzati da mcabber.

Non esiste una modalità speciale di ncurses che intercetta il messaggio (dopotutto, tmuxè già in esecuzione come applicazione terminfo). Probabilmente puoi aggirare il problema reindirizzando il tuo echo(preferibilmente printf) su /dev/tty, ad es.

#!/bin/sh
printf '\033Ptmux;\033\033]9;foobar\007\033\\' >/dev/tty

I programmi tmux e screen non passano direttamente attraverso le sequenze di escape. Presentano un tipo di terminale all'applicazione (tipo terminale schermo) ed è esso stesso un'app ncurses per un altro terminale. In effetti è qualcosa come un traduttore terminale. Quindi sì, consuma (o scarta) le sequenze per un tipo di terminale "schermo" e crea un buffer che vedi. Quindi accetta quegli eventi di modifica del buffer e utilizza qualsiasi tipo di terminale che si sta attualmente utilizzando per visualizzare il buffer corrente. Quindi l'app originale e il terminale di visualizzazione sono disaccoppiati.

Se dovessi mettere qualcosa come ...

export "PTTY=$(tty)"

... nel tuo caso /etc/profileper ogni nuova -lshell di Ogin invocheresti (che è ciò che generalmente accade quando apri una nuova finestra terminale) quella variabile d'ambiente sarebbe resa disponibile a tutti i suoi processi figlio - che dovrebbero includere tmuxe tutti i suoi figli .

Questo dovrebbe consentirti di fare ...

printf '\033]9;foobar\007' >"$PTTY"

... e quindi saltare attraverso tutti i ptylivelli che potrebbero esistere tra la shell corrente e l'emulatore di terminale che si sta utilizzando.

Se il problema è che l'output del tuo script bash si sta perdendo, puoi vincere la battaglia con il reindirizzamento:

echo "\ ePtmux; \ e \ e] 9; foobar \ 007 \ e \"> / dev / tty

Tuttavia, sospetto che il vero problema sia che dovresti usarlo in echo -emodo che bash elabori le sequenze di escape nella tua stringa.