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.
--
[PATCH] Add desktop notification of completed commands
https://bugs.launchpad.net/bugs/315932
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
