Comment 8 for bug 315932

Revision history for this message
Paul Sladen (sladen) wrote :

Been pondering this over the intervening time period; the extend depends on how narrow the focus is kept. It would probably be better to get something working reliably as a proof of concept: eg. bash and gnome-terminal for the moment:

The notification routeing can be:

  a. bash -> callout -> notify
  b. bash -> ... -> terminal -> notify

(a) only works locally, it doesn't transit SSH, but only require only a bash script entry adding.
(b) works locally *and* transits SSH (using in-band escape-sequence signalling), but not a background GNU Screen window (I believe). It requires a bash script addition and a *-terminal patch.

For the actual argumentation of the interactive environment (required for both), there appear to be:

  $PROMPT_COMMAND=/path/to/exec

or:

  $PS1=`/path/to/exec`

or:

  patching individual applications (make, wget, curl, rsync).

For the first, I've tried setting PROMPT_COMMAND='/usr/bin/env | less -S' but there doesn't appear to be any useful data passed in the environment.

As for the actual notification data, the success/fail icon idea sounds an excellent way to pass the status without wasting confusing text on it. I'd probably want to see the name of the command ("make all", "rsync foobar/ somewhere:/...", and the machine name (terminal title) if it is remote. The output only needs to be verbose enough to identify uniquely the terminal it came from; so if there are two "make all"s that were running in non-focused windows then there should be a enough to disambiguate them (yes, this needs some intelligence).

Perhaps one approach would be to specify a encoding of a passive pseudo libnotify call encoded in a (new) "ANSI" escape sequence.