Escape sequences in output of script called from ncurses application

Question

I'm currently running mcabber as my Jabber client (which uses ncurses) in a tmux session on my homeserver. Locally i run iTerm2 as a terminal emulator, which supports the triggering of growl notifications through character escape sequences.

Note: All echo in this question works like printf %b, or echo -e in bash and GNU echo.

e.g. echo "\e]9;foobar\007" makes iTerm2 send a Growl message with the text "foobar".

However, when in a tmux session, the escape sequences get eaten up. Therefore using the proprietary character escape sequence \Ptmux can be used like this:

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

This triggers a growl message from within a tmux session.

However, when I use this in my mcabber event script that gets fired when a new message is received, no notification is triggerd, as if the echo is send to the wrong terminal.

I suppose this has to do with that mcabber which triggers the script is a ncurses application so the output from my normal bash script gets lost and iTerm 2 does never see it.

I also tried calling smcup without success before echoing accoring to some ideas I discovered

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

I suppose this does not work as the issue is not switching back to the "real terminal window", but more directing the output at the ncurses window.

Any ideas on this one?

Answer 1

The reason why an event-script fails to send a "growler" message is that mcabber closes the standard input, output and error streams when it runs an event command. You can see this 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);

That makes the event script run without interfering with the streams used by mcabber.

There is no special ncurses mode intercepting the message (after all, tmux is already running as a terminfo application). You can probably work around the problem by redirecting your echo (preferably printf) to /dev/tty, e.g.,

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

Answer 2

The tmux and screen programs don't directly pass through escape sequences. They present one kind of terminal to the application (screen terminal type), and is itself a ncurses app to another terminal. In effect it is something like a terminal translator. So yes it consumes (or discards) sequences for a "screen" terminal type, and puts up a buffer that you see. Then it takes those buffer change events and uses whatever kind of terminal you are currently using to display the current buffer. So the original app and the viewing terminal are decoupled.

Answer 3

If you were to put something like...

export "PTTY=$(tty)"

...in your /etc/profile then for every new -login shell you would invoke (which is what generally happens when you open a new terminal window) that environment variable would be made available to all of its child processes - which should include tmux and all of its children.

This should enable you to do...

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

...and thereby skip right through any pty layers that might exist between your current shell and the terminal emulator you're using.

Answer 4

If the problem is that the output from your bash script is getting lost, then you can win the battle with redirection:

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

However, I suspect the real problem is that you should be using echo -e so that bash processes the escape sequences in your string.