On Tue, 13 Mar 2012, newsletter perfect-kreim de wrote:
On 03/12/12 17:53, Christian Brabandt wrote:
This is a problem in the way tmux works. It simply doesn't return
and Vim waits forever ;(
Thank you for making this clear.
I found a way to circumnavigate the problem.
The Python module subprocess works as expected. [...]
So probably tmux needs a shell to run and the vim system() function
has not this functionality (?).
Something about the way `tmux` is running fails when its stdout is
attached to a regular file. Using `strace`, it gets stuck on an
epoll_wait() call, which means that it's getting stuck in something
libevent-related. Probably for non-shell-cmd invocations of `tmux` the
event_loopexit() call isn't reached.
In these examples, you can replace 'ls' with any output-only `tmux`
command: { list-commands, list-buffers, list-sessions [= ls] }
## fails:
$ tmux ls > somefile
## works:
$ screen tmux ls
$ tmux ls | grep .
$ tmux ls > /dev/stdout
This problem was already reported on the tmux bug tracker¹. The
resolution was to start tmux with the EVENT_NOEPOLL=1 environment
variable. It's a bug in either libevent() <= 1.4 or the implementation
of epoll() in Linux.
In the tmux source code, there's a commented-out call to:
setenv("EVENT_NOEPOLL", "1", 1);
Uncommenting that and recompiling, the problem goes away. So, that's a
possibly-easier solution than having to set the variable manually.
Also note: all `tmux` instances should be stopped before testing the env
var workaround. (It takes effect the first time the server is started.)
--
Best,
Ben
¹:
http://sourceforge.net/tracker/?func=detail&aid=3489496&group_id=200378&atid=973262
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
