I normally use the up arrow key to scroll through previous commands in my terminal. I've noticed that over the past few months, when I do this, I do not get previous commands but instead a 'buggy behavior'. For example, when I press the up arrows key, it might enter gibberish and apparently random spaces and a small part of my command. Does anybody have any ideas as to what might be causing this? Sometimes it works, sometimes it doesn't work. It's starting to get very annoying. (fyi, I'm using yosemite and osx if that has any relevance)
I know this is an old question, but I recently had the same issue. The problem is likely your PS1 prompt. You may not be fully enclosing your non-printing characters with \[ ... \]
To solve:
in your terminal echo $PS1 - this will show you your current PS1 setting.
Make sure that any options (such as color options) are enclosed by \[ and \] and set it. e.g. PS1='\[\e[95m\]\u \[\e[93m\]\w:\[\e[92m\]\$'
Save your new PS1 permanently in your .bash_profile or wherever you keep your bash settings.
Example:
My faulty PS1 was \[\e[95m\]\u \[\e[93m\]\w: \e[92m\]\$
I was missing the opening encloser, \[ after the \w:
My corrected PS1 is \[\e[95m\]\u \[\e[93m\]\w:\[\e[92m\]\$
In my case, the up-arrow stopped working properly for me in OSX shortly after I changed my .bashrc to use "HISTSIZE=-1". My unconfirmed guess is that the bash version is too old to handle the -1 option, so bash stopped recording a history entirely. My up-arrow key was being interpreted correctly, but there was no history to retrieve. Once I changed my HISTSIZE, the up-arrow (and the history command) in new terminals started working again.
To be clear, I can't say if your problem is from the same cause. I don't recall getting gibberish in the history, though I did see some odd behavior such as an errant "." somehow appearing in ls commands. Still, if someone is having problems with using the up-arrow to retrieve previous bash commands, it seems worth a shot. Try checking your HISTSIZE setting, and/or invoke the history command directly, to make sure that you have a history for the up-arrow to retrieve.
I've had this problem for a while myself on my work computer I was able to resolve it when changed from ksh shell to the bash shell.
I'd recommend this Lynda course it explains most of what you need but simply type bash to change shell.
https://www.lynda.com/Mac-OS-tutorials/Unix-Mac-OS-X-Users/78546-2.html
Related
I recently switched from bash to zsh and now the tabstops in my Ultisnips-snippets aren't working properly anymore.
I didn't change anything in my snippet files and after I encountered the problem for the first time, I went back to bash, started vim from there and the snippets worked as intended again.
I have these to snippets
snippet ( iA
($1)$0
endsnippet
snippet mk wA
$$1$$0
endsnippet
If I run vim from bash and type mk, it will expand to
$Cursor$
(I will denote the cursor position by Cursor). Then I can type f( and it will expand to
$f(Cursor)$
If I press x and then tab it will take me to
$f(x)Cursor$
(I will call this previous step S). Pressing tab again I will arrive at
$f(x)$Cursor
Running vim from zsh however, I can still do the steps until S but if I then press tab, it will stay at
$f(x)Cursor$
and start inserting tabs after that. If I only do mk however and type something else without brackets, for example ab
$abCursor$
and then press tab, it will work as expected and get me to
$ab$Cursor
Does anybody have an idea what's going on here? What can I do if I want to keep using zsh and Ultisnips? If I run bash -c 'vim file.txt', vim will work really slowly and lag a lot, so that is not really an option.
Any help would be appreciated.
Edit: Apparently the problem has something to do with what version of vim I'm using. I use macOS and the problem I described happens when I use the default vim version. If I use a custom-compiled version of vim, it works as expected. And as it turns out I have some config file that tells bash to use the custom-compiled version, whereas zsh still uses the default one. I also tried it on my PC (running Ubuntu) and with the vim version installed there, it also worked. So I guess, I'll use my custom-compiled vim to avoid this problem...
But does anybody know, what vim setting could be responsible for this? If I'm not mistaken my custom-compiled version is just the huge-feature version of vim.
I encountered some bizarre Bash behavior today, and maybe it's a bug that's since been fixed, but I'm going to ask about it anyway.
I have an x64 Cygwin install on my work computer with Bash 4.3.46 in it. By accident today, instead of typing !533 to run an old command in my history, I typed ~533. That should have just displayed nothing, since I had an empty directory stack.
But instead, ~n seems to freeze Bash, for any number n. Open a brand-new MinTTY with Bash in it, type ~1 and hit Enter, and Bash just disappears into la-la land. Ctrl+C, Ctrl+J, Ctrl+Z, Ctrl+anything can't get you back to a prompt. Characters you type are echoed to the console, which is mildly interesting, since something must still be echoing them. But you can't recover the shell, and you can't even close MinTTY normally — you have to force-kill the Bash process ID.
It's worth noting that dirs +1, which is supposed to be the equivalent of ~1 (per the Bash manual), works just fine.
I can reliably reproduce this on my work computer. Interestingly, Cygwin Bash 4.4.12 on my home computer works right, so this may be a bug in the 4.3.x versions that they fixed in 4.4.x. If it is a bug, I'll definitely upgrade.
So is this broken tilde behavior a bug? A misconfiguration? Has anyone encountered this behavior before?
I just switched to a windows machine and I'm trying to get fish configured correctly. I installed it through the default route, as a shell selected through cygwin setup. It seems to be working fine, but when I directly access fish.exe or run fish.exe through IntelliJ, it outputs a ? before very prompt:
I googled and found this on fish documentation FAQ:
I'm seeing weird output before each prompt when using screen. What's wrong?
Quick answer:
Run the following command in fish:
echo 'function fish_title;end' > ~/.config/fish/config.fish
Problem solved!
The long answer:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Note that fish has a default titlebar message, which will be used if
the fish_title function is undefined. So simply unsetting the
fish_title function will not work
So it appears that intelliJ and cmd (fish.exe runs in cmd.exe if you access it directly) do not support setting the title bar, so they just output the character to the terminal instead. However, their suggested solution does not work. I've tried various options like echoing an empty string or a space, but nothing gets rid of that darn question mark.
Has anyone else run into this and found a solution?
Notes:
It doesn't have this behavior when using fish through mintty.exe,
most likely since that terminal supports setting the title, but I really prefer
to use the terminal inside intelliJ instead of having it in a
separate window.
It didn't have this problem when I used fish through IntelliJ on Ubuntu or MacOSX, it appears to be isolated to Windows
I'm running zsh with oh-my-zsh on OS X. Every time I use zsh's awesome tab-completion, formatting on the current command line prompt gets really screwed up. For example:
I'll be typing cd fo and try to tab-complete for the 'foo' directory; zsh prompts for completion but changes the command line to cd fo cd fo while it's waiting for me to complete. It's not a big deal but very annoying. Any suggestions?
I had the same issue on PopOS and Arch linux. I tried a bunch of solutions from various places but the only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
The solution is to make a copy of the .zsh-theme file of whatever theme you're using in oh-my-zsh and surround all non-ASCII characters (like emojis) with %{%G<CHARACTER>%}
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
solved the issue for me.
I have faced the same problem before, my solution was disabling some zsh plugins. The second probability is that your colour theme may contain a bug which causing this.
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
This is the final version of my plugin section in the ~/.zshrc file. Any other plugin between parenthesis may be the reason of your situation.
If your problem still continues you need to post your ~/.zshrc to let us check what is in there.
I had the same issue. Interestingly, I saw the problem only iterm2 while the prompt is correctly displayed in the standard terminal of OS X (after reverse-i-search/tab-completion). The reason seems to be that iterm2 defaults to Unicode (UTF-8) default encoding, which however is not correctly interpreted if the corresponding language variable is not set in the shell.
Solution: add the following to your .zshrc
export LC_ALL=en_US.UTF-8
The prompts will be displayed correctly.
I'm on OS X Mountain Lion, running the included ZSH shell (4.3.11) with Oh-My-ZSH installed over the top.
When using tab completion with commands such as homebrew, when ZSH lists the available commands, it is also duplicating the command. For example:
$ brew {tab}
will result in:
$ brew brew
[list of homebrew commands]
I'm unsure what is causing this error, as when I resize the terminal window, the first instance of the command name disappears.
If I hit backspace when the duplicates are displayed, I can only delete the second instance of the command, zsh won't let me backspace any further. Also, if I do remove the duplicate with backspace, zsh then acts as if there is no command typed at all.
My .zshrc along with all my other .configuration files can be found at https://github.com/daviesjamie/dotfiles
UPDATE: I found this post about someone having the same problem on Ubuntu. However, I don't understand the given solution, and I'm not even sure if it applies to my set up?
This effect also could be reproduced if you use any of fancy UTF-8 characters like arrow, "git branch" character and so on.
Just remove this chars from prompt and duplication will not occur.
Also adding
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
to ~/.profile can help
The problem is likely to arise from misplaced %{ %} brackets that tell zsh that text inside has zero width. The only things that should be enclosed in them are escape sequences that change color or boldness of the text. If you are using new zsh (>=4.3.{unknown version}) I would even suggest to use %F{color}...%f, %K{color}...%k, %B...%b instead of %{${fg[green]}%} or what you have there.
The problem with them is that there is no way to query the terminal with a question like “Hey, I outputted some text. Where is the cursor now?” and zsh has to compute the length of its prompt by itself. When you type some text and ask zsh to complete zsh will say terminal to move cursor to specific location and type completed cmdline there. With misplaced %{%} brackets this specific location is wrong.
If you use iTerm on Mac, be sure to check "Set locale variables automatically" in your profile preferences. I had it unchecked for an SSH connection and it resulted in the same bug and I fixed it by leaving that option checked.
It's an old thread but I faced similar issue in my zsh setup with oh-my-zsh configuration.
Setting export LC_ALL=en_US.UTF-8 fixed the issue.
A lot of answers in a lot of places suggest the export LC_ALL=en_US.UTF-8 solution. This, however did not work for me. I continued to have this issue using oh-my-zsh on both Arch linux and PopOS.
The only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
It turns out, at least in my case, that the autocomplete duplication issue would only show up if there was a non-ASCII character somewhere on the line (like an emoji). And ZSH would incorrectly assume that this non-ASCII character needs to take up 2 character spaces instead of 1.
So the solution that worked was to open up the .zsh-theme file of whatever theme you're using, find all non-ASCII characters and use %{%G%} to tell ZSH to only use one character width for that character
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
is what finally fixed the issue for me.
So all you need to do is make a copy of the theme file you want to use and edit all the non-ASCII characters as shown above and you should hopefully never see the duplication issue again.
My solution to make both local and ssh work is something like a combination of #Marc's and #neotohin's answers:
Set export LANG=en_US.UTF-8 (simply uncomment that part in the template .zshrc; exporting LC_ALL, as in #neotohin's answer, instead of LANG may also work, I didn't try)
Uncheck "Set locale environment variables on startup" in the Terminal profile's "Advanced" section (reason: that setting sets LC_CTYPE=UTF-8 instead of en_US.UTF-8, which brakes the locale for me in ssh)