Welcome to Vifm Q&A, where you can ask questions about Vifm usage. Registration is optional, anonymous posts are moderated. GitHub or Google logins are enabled.

How to get history working in bash on windows

0 votes
asked Feb 8, 2017 in vifm by Dan Osborne

I've installed vifm in bash on ubuntu on windows using

apt-get install vifm

and am pleased to see that it basically works but there seems to be no command history

There is no .vifm/vifminfo file created (though there is a vifmrc, Trash etc).

The output from vifm --version is...
vifm 0.4

Do I need a later version perhaps?



1 Answer

+1 vote
answered Feb 9, 2017 by xaizek
selected Feb 10, 2017 by Dan Osborne
Best answer

Do I need a later version perhaps?

Yes, definitely. v0.4 is very old, buggy, lacks many things and configuration is completely different there.

If that's all they have, you might need to build vifm from source package. Instructions are here. You'll need a build tools though, like gcc, I think there was a package like "build-essentials" to install them.

commented Feb 14, 2017 by Dan Osborne

I have now built version 0.8.2 and do get a vifminfo file and command history.

However I'd appreciate some help in configuring it. Currently to move up and down the list of files in a pane I have to use J/K, if I try and use either the up or down arrow it tries to launch gvim...

/bin/bash: gvim: command not found
Press return ...

My $TERM is set to xterm...
$ echo $TERM

$ vifm --version
Version: 0.8.2
Git info: built out of repository
Compiled at: Feb 13 2017 10:08:56

Support of extended keys is on
Parsing of .desktop files is enabled
Without GTK+ library
Without magic library
With X11 library
With dynamic loading of X11 library
With file program
With -n option for cp and mv
With remote command execution

commented Feb 14, 2017 by xaizek

In bash you can try pressing Ctrl-V Down and see the output. In xterm it's ^[[B but you might get something different, which is unknown to curses. Then you can try mapping those sequence to execute <down>. I wouldn't expect this to be needed if their support is solid, but maybe there is something we're missing or it's a bug.

commented Feb 15, 2017 by Dan Osborne

Yes, it outputs ^[[B

The 0.4 version behaved itself in this regard if that gives any clues.


commented Feb 15, 2017 by xaizek

That's strange. I installed this thing and 0.4, 0.8.2 and current development version work the same with arrow keys working fine. Did you remove ~/.vifm/ directory? If not, try doing that. If it doesn't help or you did that already, see what :nmap <down> outputs in vifm. Maybe there is a conflicting mapping of some sort.

commented Feb 16, 2017 by Dan Osborne

Yes I did clear that out.

nmap output attached. The box drawing looks a little suspicious. Building it myself is probably to blame - recent builds are supposed to have Ubuntu 16.04 which has more recent versions of vifm (I'm on 14.04 currently). I may have to brave the windows insider program to get that though.


commented Feb 16, 2017 by xaizek

Building manually shouldn't introduce any such side effects (it didn't for me). Screenshot looks like a font issue, but maybe something is wrong with locale, what's the output of locale in terminal? Also I suggested to run :nmap <down> instead of just :nmap to see binding for this specific key, but I'm not sure if that will help.

commented Feb 16, 2017 by Dan Osborne
edited Feb 16, 2017 by xaizek

Ah sorry, :nmap outputs "go to item below"

and locale says...

commented Feb 16, 2017 by xaizek

OK, I reproduced it. Looks like it happens for me only if I open cmd window and start bash from there and do not change focus on another window (all of this is weird).

I'm bisecting to see what might be the cause, but for now try starting bash in some different way. And I get wrong box characters for fixed font, but all is fine for couriel new or consolas.

commented Feb 17, 2017 by xaizek

There is line 178 at src/ui/ui.c:


Replace 0 with 5, this should fix it.

It works as is on most systems because they insert all bytes atomically, apparently it's not the case here. Generally speaking the delay might be useful on other systems in corner cases as well and shouldn't be noticeable, so I'll probably make this change for all systems.

commented Feb 20, 2017 by Dan Osborne

Well, bash on windows was bound to be weird! My prompt was run from the standard icon that has target: C:\Windows\System32\bash.exe ~

However, I did an apt-get upgrade before getting your latest reply and this seems to have sorted it. It upgraded these packages...
bind9-host:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), liblwres90:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), libdns100:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), libisccfg90:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), libbind9-90:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), dnsutils:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), libisccc90:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12), libisc95:amd64 (9.9.5.dfsg-3ubuntu0.11, 9.9.5.dfsg-3ubuntu0.12)

I've made your code change and re-built for completeness but my suspicion is that bash on ubuntu on windows is a little flaky,

Thanks for investigating,


commented Feb 20, 2017 by xaizek

There is more to its weirdness. After it starts working (also happens if you run another application, not just vifm), it works until you restart the bash. This might explain how upgrading "fixed" it.

If you would like to make a bug report or feature request consider using GitHub, SourceForge or e-mail. Posting such things here is acceptable, but this is not a perfect place for them.