I'm using CentOS 6. Since the CentOS repos have an older version of vim (7.2), I have compiled my own. However, I am having a weird issue. After running and exiting vim, I've found that my shell prompt has disappeared. Also, when I type, it does not appear in the terminal, nor does any output. What's weird is that it looks as though something is being outputted, since the cursor will move down the screen, but I can't see anything.
It must have something to do with compiling an X version, because it does not happen when I compile vim without X windows support (but I would like to have gvim, too). Here are the configuration options I supplied when compiling:
./configure --prefix=$OPT/Cellar/vim/7.4 --with-features=huge --enable-gui=auto --with-x --enable-xim
I also tried compiling without Xim. I've also tried explicitly setting --enable-gui=gtk2 (which is what gvim 7.2 from the CentOS repos uses).
I am using KDE4. The problem occurs both when running tcsh and bash. I have tried with $TERM set to both xterm and xterm-256color as well.
Additionally, running neither reset nor stty sane restores the shell to its proper behavior.
Any idea why my prompt disappears when running vim? As I missing a config flag or some other compilation issue?
I ultimately traced this down to an error in my ~/.vimrc file. I had some lines like this:
if has('gui_running')
# Gvim customization
endif
if has('gui_gtk2')
# GTK2-specific Gvim customization
endif
The second block was running every time vim loaded. Because it changed some window geometry, it ended up messing up bash; when I dropped back to bash, bash thought it only had ~53 columns to work with (and possibly some other things were messed up).
Solution: The second if block should be inside the first.
Related
When editing with vim, the normal exit code is 0. For example:
vi; echo $?
will return 0 if you just do :q immediately. However, it will return 1 (or other error codes) if you ever enter a bad command. For example, typing :aaa in vim will give the error E492: Not an editor command: aaa in vim. After that point, no matter what I do, vim will subsequently exit with status 1.
This is a problem when editing git commit messages, because if you ever make a mistake while typing (easy to do in vim), the subsequent commit message will be thrown away. (Yes, I know there are ways to retrieve it - I don't want that hassle every time I know I made a mistake.)
The question: is there a vim command to "reset" the exit code to 0?
There is a similar question here: can i force vim to exit with 0 status. However, that one is due to using vi instead of vim, which (apparently) exits with non-zero if you search for a non-existent string. This question is specifically about vim.
Edit: Thanks for the answers here! Some additional details:
this is on MacOS 11.2.1.
I have no ~/.vimrc so I'm just falling back to the Mac-provided /usr/share/vim/vimrc, which seems pretty basic.
calling vi -u NONE still causes the behavior described above.
(most interesting) calling vim fixes the problem. Yes, I know I mentioned above that the other answer was using vi instead of vim, but I was thrown off by this:
$ which vi
/usr/bin/vi
$ which vim
/usr/bin/vim
$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 Jan 1 2020 /usr/bin/vi -> vim
And when I run either vi --version or vim --version, I get identically the same output. Does vim change its behavior depending on the calling executable name? And if so, is there something I can stick in my .vimrc to override whatever that switch is? I'd love to know. In the meantime, I can fix this with export EDITOR="vim".
By default, Vim (and at least some other implementations of vi, such as nvi), return 0 if a "normal" error occurs, such as an invalid command or another normal user input error. It is the behavior of ed to exit nonzero in such a case, and as you've found, that behavior is generally undesirable because humans are imperfect and make many mistakes, which is why Vim doesn't do that.
Vim should exit nonzero if you use :cq, which has this behavior intentionally, as well as if certain error conditions are met (e.g., you run vim -y but the display cannot be started.
It is possible you have a configuration setting or plugin that causes this behavior. You can try running with vim -u NONE -U NONE to verify this, and then isolate the problem by commenting out portions of your .vimrc. It is also possible that your Vim distributor thought this would be a desirable feature to add and patched it in for you, but you haven't mentioned your OS or source of Vim packages, so it's hard to say.
To always force a zero exit, you can try :cq 0, but that is no more likely to work than a standard :q, since they both call the exact same function (getout) with the exact same value (0).
I'm seeing this behavior as well on macOS 11.6, and it only happens when invoked as vi – not vim.
Why does this happen?
If we look at vim --version:
> vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 30 2021 06:51:40)
macOS version
Included patches: 1-2029
Compiled by root#apple.com
The macOS version here let's us know that something might be up.
Looking at vim's main.c in the Apple's open source repository (https://opensource.apple.com/source/vim/vim-91/src/main.c.auto.html), we find this inside the int main() function:
Unix2003_compat = 0;
if (strcmp(base,"vi")==0) {
Unix2003_compat = COMPAT_MODE("bin/vi", "Unix2003");
} else if (strcmp(base,"ex")==0) {
Unix2003_compat = COMPAT_MODE("bin/ex", "Unix2003");
}
and then in void getout(int exitval):
if (exmode_active || Unix2003_compat )
exitval += ex_exitval;
The Unix2003_compat parts here are not present in the official Vim sources.
So on the macOS version of vim, if invoked as vi or ex you'll get this error preserving behavior.
Note: The Apple URL is confusing – vim-91 really corresponds to vim 8.2, which can be checked by looking at version.h in the same repo.
Solution
Invoke vim as vim instead of as vi. In the case of git set the EDITOR environment variable to vim in your .bashrc/.zshrc/config.fish.
Alternately, install the official vim through something like Homebrew.
SOLVED: the problem was this line in my .vimrc:
set shell=/bin/bash\ -li
UPDATE: it appears the problem is due to my .vimrc (renaming the .vimrc to 'hide' it fixed the problem), so it probably has nothing to do with Mint.
I'm running Linux Mint 17 Cinnamon. When I run vim -d file otherversion in the terminal, I get a blank screen with
"otherversion" 18L, 218C
[1]+ Stopped vim -d file otherversion
user#machine:~/path/to/directory$ ;2R
If I do fg 1 that terminal window just closes. Also, there's no blinking cursor, though I am able to type. Same with vimdiff instead of vim -d. I've tried multiple distributions of vim, some that include the GUI, some that don't.
However, with versions that do include the GUI, if I run vim -d -g file otherversion, it works as expected.
I'd rather not depend on gvim to use vimdiff.
Any advice?
Thanks
If you need an interactive bash shell (to get your bash aliases for instance), use this code in your .vimrc instead of removing the option:
if &diff == 'nodiff'
set shellcmdflag=-ic
endif
This will only enable the interactive bash shell when not running vimdiff, so that you will have you bash aliases when running vim.
After removing the following line from my .vimrc, the problem went away:
set shell=/bin/bash\ -li
Thanks to comment from #FDinoff, the same problem at my end got solved.
The problem was "bash" command in my ~/.cshrc.
I had put that to avoid entering into bash every time after login. It was working fine until this issue started coming whenever I used to open vimdiff.
Removing ~/.vimrc didn't help me either. Then I read comment from FDinoff. There, he suggested that it could be related to shell, if "less" and "man" have also stopped working. I observed the same issue in my case, that helped me rule out the corruption in .vimrc.
After removing "bash" from my ~/.cshrc, the problem went away completely.
When I run gvim from MSYS, things go wrong during initialization. Namely, gvim can't find the initialization files that are in 'C:\Documents and Settings\username\vimfiles.
[Specifically, gvim reports the error E117: Unknown function: pathogen#infect during initialization, so it never found autoload\pathogen.vim. Doing :scriptnames also confirms that none of the setup files from vimfiles\ are run.]
I think I've debugged why it goes wrong. When you start MSYS, the MSYS shell inherits the windows enviroment variables, but changes some of them to it's custom values. C:\Documents and Settings\username is the value of $HOME in Windows, but MSYS sets it to something like C:/msys/user name. And of course, Vim uses $HOME to find the right initialization files.
I also notice set shell? has changed to something like shell=C:/msys/bin/sh instead of shell=C:\WINDOWS\system32\cmd.exe, but I hope this isn't important for fixing the initialization problem.
I need to run gvim with the normal windows environment variables. At least I need to be able to manually override a few important ones like $HOME to something I specify (i.e., I'm not concerned about my windows $HOME changing, so it's fine to use a static value).
I tried to reset $HOME manually in my vimrc, but by then it is too late.
Is there some trick to specifying $HOME early on during initialization, or as an extra command line parameter?
Alternatively, is there some trick with running commands from msys differently? I know almost nothing about how the shell C:/msys/bin/sh works, but I could conceive of some extra arguments that changes the visibile environment for the command (e.g. gvim.exe) you are typing.
---Edit---
Reposting the solution that worked (it achieves the later idea):
Instead of running gvim.exe, run the command HOME="C:\Documents and Settings\username" gvim.exe
In bash and other UNIX shells, you can do:
$ HOME='/path/to/dir' gvim
to temporarily set $HOME to a different value.
I admit I'm not familiar at all with the Windows command line, but it might be worth a try.
I believe you can define $HOME just like any other environment variable.
Try adding this to the start of your .vimrc.
let $HOME="C:\Documents and Settings\username"
I had a similar issue when running Cygwin (which is similar to MSYS).
The easiest solution for me was to simply set the HOME environment variable to an empty string. Otherwise, the Cygwin HOME value would be appended to the Windows USERPROFILE in GVim and it would fail to start correctly. Not explicitly setting the full path of the HOME means that I can use the same start-up files on different systems where the USERNAME may not be the same.
Likewise, the SHELL environment variable should not be inherited from Cygwin Bash. This results in errors when running shell or external programs via !. Again, I set this to be an empty variable since Vim is smart enough to figure out what it should be.
In my .bashrc, I set the following alias for running Windows gvim which starts GVim with the HOME and SHELL variables set to an empty string – just for that command.
gvim="/cygdrive/c/Program Files (x86)/Vim/vim74/gvim"
if [ -x "$gvim" ]; then
alias gvim="HOME= SHELL= \"$gvim\""
fi
unset gvim
I achieved this by making a windows symbol link (Win 7 or higher).
Via a symbol link, you can even make vim and gvim to use the same configuration and plugin.
I cannot see any syntax highlighting in any language (e.g. python, c++ and sh) when I use vim within a screen session. The line numbers are in color though.
I precise that my terminal (in screen too) is able to show 256 colors schemes (I tested with the 256colors perl script found here: http://frexx.de/xterm-256-notes/ ).
How can I fix that?
OK, here is the issue/solution:
I used to call vim by using $vi, indeed:
$ which vi
alias vi='vim'
/usr/bin/vim
But:
$ screen
$ which vi
/bin/vi
I just learnt that screen doesn't load this system level alias which is tricky.
I had this problem. In my case, I was running a version of screen from brew. brew doesn't use ~/.screenrc as its startup file. So there's two solutions to this.
1) Set your term in the screenrc that brew_screen is expecting. This might be /opt/etc/screenrc. I didn't try this method, so I'm not sure.
2) Make an alias for screen that sets the term to what you want it to be. In this case, screen-256color is sufficient. I added the following line to my bash_profile, which is symlinked to my bashrc (mac problems):
alias screen='screen -T screen-256color'
I am trying to use rxvt on my cygwin w win XP but the terminal appears and disappears. What could be wrong? This is true for all except rxvt-native . I have tried a few commands found online but with no success. I include 2 I have tried:
start C:\cygwin\bin\rxvt.exe -sb -sl 3000 -fg gray -bg black -fn "Lucida Console-14" -e /bin/bash --login -i
.
path C:\cygwin\bin;%path%
ssh-agent rxvt -e bash --login -i
Another problem I am facing is trying to get vi to work in my cygwin bash shell. Setting term to xterm or vt100 does not work. Hitting enter, I see a string 78 or some other issue pops up. I have never modified my .inputrc.
My main issue was trying to get vi to work properly. I just found out that if I run
/etc/postinstall/terminfo.sh.done , I can now navigate properly in vi. The 78 (newline) M still appears but at least I can navigate in vi.
Feb 25 - This problem went away after a few windows updates. Would it make sense to ANSWER my question on the basis that this is longer reproducible?
Can't answer the first question, but have you tried invoking rxvt from its shortcut in the Cygwin folder of the start menu?
Regarding the second question, the TERM variable tells applications what terminal they're running in, so if you set it to 'xterm' while running in the Cygwin console (where normally TERM=cygwin), they'll be sending xterm control sequences that the Cygwin console doesn't understand. So basically: don't do that!
Btw, you might also be interested in Cygwin's mintty package, which is another terminal that doesn't need an X server. Installing it also creates a start menu shortcut in the Cygwin folder.
I would assume you need an X server running.
You could install Cygwin/X
One thing which may not have been clear was that the whole exercise was to get vi to work. vim did not work either at that time. But after some windows update, the problem went away. Closing it...