Closed simlei closed 1 week ago
Here is what I've done and what now works for me: https://github.com/simlei/vim-dispatch/commit/c580099a4cadd839dac71ba0056207c46a08fc49
From the :help
:
X11 ~ Uses g:dispatch_terminal_exec, "$TERMINAL -e", or "xterm -e".
The default is already xterm -e
. All you're doing by setting g:dispatch_terminal_exec
is removing the -e
, which unsurprisingly breaks everything.
Hi tpope,
I encountered today a confusing behavior of the
x11
dispatch strategy. The upside is, it's rather not the fault of vim-dispatch. The bad news is, this is thexterm
delivered by default to my Ubuntu 20.04 (yeah I need to upgrade ^_^).The rundown:
I'm configuring dispatch like this, so that spawn chooses
X11
as strategy.I do
:Spawn env
.Nothing happens but an
:echo
telling me the process was spawned.I trace down this behavior; I'm arriving at
vim-dispatch/autoload/dispatch/x11.vim
/function! dispatch#x11#spawn
. It has asystem(...)
call at the end. I inspect the argument to that system call. It is:I run this command manually in a terminal. It's output is:
and it's not terminating by itself, i.e. I have to
<C-c>
to get to my prompt. weird.XTerm version:
I inspect the xterm man page. It says, it inspects
/etc/shells
to see whether one leading non-option argument is in it. In this case, it should find/bin/bash
, stop trying to read options and pass the following arguments to it. However, that's not what it does according to it's output; it seems to try to match the-c
to it's list of option flags.A shame :( Just want to report this. I'm working around this myself now by writing the argument to the
system(...)
call to a temporary executable file and telling xterm to run that. Let me know if you're interested in a pull request of that workaround.Cheers, a fan.