So, I recently discovered that if automatic window-renaming is on
(default), it's possible for a program's name to influence how the
window is rendered in the status bar, since '#[...]'-style formatting
instructions are handled in a second sweep (in status_write_cnputs),
_after_ the window's title has been interpolated.
I wasn't entirely sure this was unintentional, but it's not documented.
I was planning on preparing a patch for this, but it has since occurred
to me that it could be put to use. For instance, a feature I've long
wanted is, when I invoke an editor (vim, say) on a file, then the status
would show the filename I invoked it on, with special formatting,
instead of vim. Screen doesn't do this, tmux doesn't do this, and I
don't bother to bring it up because a generic implementation would
require a small embedded scripting language.
However, I realized I could know whip up a program like:
------------------------------------------------------------
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <stdio.h>
int
main (int c, char **v) {
char new_arg0[100];
if (c == 1)
return 0;
if (c > 2) {
char **fname, *ename, *tmp;
for (fname = v + 2; *fname != NULL && **fname == '-';
++fname) {}
if (*fname != NULL) {
tmp = strrchr(*fname, '/');
if (tmp) ++tmp;
else tmp=*fname;
snprintf(new_arg0, sizeof new_arg0,
"#[fg=blue]%s#[default]", tmp);
ename = v[1];
v[1] = new_arg0;
execvp(ename, v+1);
}
}
return 0;
}
------------------------------------------------------------
If I compile this with "gcc -o wtitle wtitle.c", and alias
vim='/path/to/wtitle vim', then type "vim README" in the shell, tmux
will render the title with "README" in blue, rather than "vim" in the
default attributes.
(Note that this isn't very robust: it won't work if I use any vim
options that expect an argument; it'll display the option-argument
instead of the file (unless I remember not to put a space between the
option and the argument, maybe)).
OTOH, a similar effect could be achieved by creating a wrapper script
that just manipulates the window-status-foo variables for the current
window, runs the program, and sets them back to their previous values
(Ain't tmux grand? Can't do that in screen), but that has some problems
that are avoided by the wtitle.c solution: it inserts an otherwise
useless shell process, which is the process group leader instead of the
"real" program; something (kill -9?) could prevent the script from
restoring the window settings; the window status won't be right if the
user suspends the process group (unless the script is smart enough to
catch SIGTSTP), etc. There's also a race condition: if the user switches
away to a different window while the script's not done setting things up
(or tearing them down), the wrong window will have its attributes
munged. This program-name hack avoids all those issues (while
introducing the new one that it looks ugly in ps(1) results).
So what do you guys think? A bug that should be fixed? Or a cool,
surprise "feature" to be exploited (possibly with a configuration option
that allows one to disable it)?
-mjc
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
