Sometimes when I use bash, when everything is going right
I get prompts like this:
user#name$
user#name$
user#name$
For some reason, I do not know, sometimes my terminal gets "damaged" and I get this:
user#name$ user#name$ user#name$ user#name$
and everything I write is hidden. So I had to shut down this terminal tab and open a new one. How do I fix that?
This is usually not a shell-related problem. Did you cat a binary file by accident?
Assuming you are on Linux or another Unix-like system, try
stty sane
to set sane terminal settings again. The stty(1) manual page makes for interesting reading. :-)
Related
I'm trying to setup the terminal on my new Mac to match the behavior of my old Mac, however I have run into an issue with my multiline prompt that has me stumped. I remember having this issue when I setup my old Mac several years ago, however I don't remember how I solved it.
My prompt (without color) looks like this:
╭─username ~ 130 ↵
╰─
When I press ⌘commandK in iTerm2 on my old Mac it clears the terminal window so that both lines of the prompt are shown at the top.
When I press ⌘commandK in iTerm2 on my new Mac it clears the terminal window so that only the second line of the prompt is shown at the top.
I have tried checking everything I could think of, I have checked:
Every dot file/directory in my home directory (copied them to the new Mac).
iTerm2 settings.
System settings (primarily keyboard shortcuts).
Various websites with instructions about setting up multi-line prompts.
Interestingly I have discovered that if I type clear iTerm2 will clear the screen and leave the top line showing on both Macs. However it first clears the entire screen, including the prompt, before bringing the prompt back (looks bad imo). However since it works differently ⌘commandK does I don't think that's what my old Mac is doing.
It's possible that I installed some program/script that somehow does this, but if so I'm not finding it locally or referenced online.
Does anyone know how I can get ⌘commandK working to clear the screen while keeping the top line of my prompt? I still have the old Mac so I can check/compare anything on it to the new Mac if there are any guesses about what settings I changed.
Edit:
I was able to find something that worked, however if anyone has any other suggestions I'll be happy to try them and accept any that I can make work that are less hacky than this (e.g. don't require another 3rd party app).
Edit: This doesn't work while a command is running, nor does it clear the scrollable history. So it's better than nothing but still doesn't behave like I want it to.
After coming back to my question SO associated a new question with an answer I was able to make work, although it feels extra hacky and wasn't what I had working before.
I found this answer which suggests using ⌃controlL to clear the screen. That does exactly what I want it to do (leaves the top prompt visible and doesn't flash) but with the wrong keybinding. Fortunately I was able to use an app I already have installed (BTT) to make ⌘commandK map to ⌃controlL only in iTerm2.
In most of the time, my zsh works correctly:
However, sometimes its behaviours became weird, and I would like to know how to deal with this problem. (So far, I have to open a new terminal tab to have the correct output).
My .zshrc is here, which was modified from https://github.com/jez/dotfiles
stty sane might bring back your terminal to a correct behavior.
I am at a loss here. I use GIT by opening up a DOS window, which launches Ruby 2.0.0.
When I do a GIT diff, it gives me a blurb, but then leaves me in some sort of editing limbo with the prompt saying (END) instead of c:... (see screenshot)
I've tried Ctrl^C and :q and a bunch of other things but I cannot seem to escape this mode.
In the screenshot you can see that I typed Ctrl^C and it LOOKS like I've escaped back to the Cmd prompt, but the moment I try to type anything else, it puts me back in the (END) mode.
I do not understand what I've done to get in this mode, or what I do to escape it.
By default git diff drops you into a pager such as less or more. Control-C may not break you out of the pager, but you should be able to just hit q to quit. You can use git --no-pager diff so it doesn't use a pager at all.
Possibly something, or someone, changed your ~/.gitconfig file. That can override a lot of standard git behaviors.
q seems to have worked - THIS time.
It was naturally one of the first things I tried, but it was not working. Don't know what I was doing wrong, but it's working now. (Perhaps I will return if/when it stops working again.)
I searched some old answers on stackoverflow, some of them seem relevant, but none of the solutions work on my macbook (with mountain lion). e.g. The shortcuts mentioned in answers here do not work on my computer: How do I run a terminal inside of Vim?
So I'm wondering if it's because vim on mac/unix is different from a normal linux one. I don't think so, but I'm not sure.
Since I can split the screen with :sp, I'm wondering if it's possible to use one split as terminal and another as the regular vim editor, just like emacs. If so, what's the correct way to do it? (Maybe particularly for mac) If not, it's sad.
Why don't you do things the other way around?
You can use a terminal multiplexer such as Tmux and split a terminal window into two panes using C-b %.
Inside the second pane you can run macvim inside a terminal with $ mvim -v
You can navigate between the two panes with C-b o, (And do much more, but I'll leave it up to you to discover!)
Doing things this way around is much more sane in my opinion, you get the full power of both the terminal and vim without having to hack around with Vim too much (Plus Tmux is very handy for many other uses).
I hope doing things this way around is appealing enough for you!
Having a terminal inside of vim would go against the author's philosophy and design so no: that feature will probably never appear nativelyly in vim.
There are a couple of plugins that more or less work like conqueterm, try them if you really want that feature. Or simply use a separate terminal window like everybody.
You should definitely look at programs like tmux or screen.
But an even simpler solution is to use C-z (which halt vim) to access the terminal and fg to bring back vim into the foreground.
I see a few entries here about making Shift-Tab work in vim, but none of them addresses the failure when it's in Cygwin, running at a Windows command prompt. In that environment, Shift-Tab works for me exactly like an unshifted tab, and my attempts at remapping have failed:
:imap <S-Tab> ^D [ this is a real Ctrl-D, entered with Ctrl-V before it ]
:imap [ typed Ctrl-V, Shift-Tab here; got a Tab character inserted ]
So it seems that the Shift modifier is being ignored. Any thoughts about how to proceed? Thanks.
That won't work in the Cygwin console because it sends the same keycode for both Tab and Shift+Tab: ^I.
You might want to install Cygwin's mintty terminal emulator, which sends the standard keycode for Shift+Tab: \e[Z.
Instead of messing with the Cygwin version, I suggest you remove it and install the native version instead. With that, you can map Shift-Tab without issues, even when starting Vim from a bash shell.
I don't have windows right here now, but look whether your vimrc contains
behave mswin
source ...\mswin.vim
In that case,
:e +g/mswin/norm!\ 0i" $MYVIMRC
should automatically comment these out. Relaunch vim, and inspect whether there are existing mappings:
:verbose map <S-Tab>
will show you any existing mappings, and where it was last defined, so you can find the script/plugin that is causing this (:he :verbose-cmd)
HTH
Update to the comment:
Well - blimey, turns out that Shift-Tab is magically impossible with Win32 Consoles. Never noticed.
Perhaps it is because I
use mintty these days, to provide a much better experience (Unix like copy pasting, real alternative terminals, more performance, and re-attaching screen sessions, e.g.)
might have tweaked the CompletionChar setting although this seems like a loose fodder even to me
Could you try with mintty? I'd think I'd have noticed such a hairy incompatibility over the years. But, you never know :)