Until recently, I was able to use an .inputrc file for defining the backspace key as meaning delete-char in bash but a few days ago, Docker Toolbox updated automatically and now bash doesn't work anymore.
Here is what I'm doing
Start the "Docker Quickstart Terminal"
Run "docker-machine ssh"
At this point, I'm in a normal shell i.e. /bin/sh and the backspace works perfectly, but when I switch to bash, it suddenly stops working. Here is my .inputrc file, not sure if it helps, it worked before the update
set completion-ignore-case on
# ctrl-left/right
"\e[1;5C": forward-word # ctrl + right
"\e[1;5D": backward-word # ctrl + left
"\e\e": kill-whole-line
DEL: delete-char
"\e[1~": beginning-of-line
"\e[4~": end-of-line
I'm using Windows 10 with the falls creator update.
Docker Toolbox: v18.01.0-ce
Bash: GNU bash, version 4.4.0(1)-release
Terminal: Windows cmd.exe
I'm going to try identify the last version when it worked, but what I would like to know is if something changed in recent Docker Toolbox versions or if I just did something wrong.
Edit:
I tested around and apparently the boot2docker version 17.12 introduces this regression.
It seems this is a bug and I didn't do anything wrong. Tracked here: https://github.com/boot2docker/boot2docker/issues/1299
Related
So, I'm new to VS code just installed it and I'm having an issue. The backspace doesn't work in the bash terminal of VS code. The backspace works on the cmd terminal of VS code though.
Not working means when I tap the backspace it prints a white space in the terminal.
Also the backspace key works perfectly fine on Git Bash
I tried googling but didn't find what I was looking for!
Please help.
You can check your TERM by running echo $TERM, but before you do this I suggest you restart your vscode as you have already set the TERM by using the command. I think your TERM was set to something incompatible.
export TERM=xterm will set the emulator to xterm.
Most application will expect that you already have the emulator set to something compatible such as xterm or linux.
For more information regarding what export TERM=xterm does you can check the following answer
Now, if you restart your vscode or terminal inside the vscode, TERM will reset to default and the problem will occur again. Therefore I suggest you add the export TERM=xterm in bash_profile or bashrc.
To add it to bashrc, type following in your terminal:
echo export TERM=xterm >> ~/.bashrc
source ~/.bashrc
go to command palette and select open shortcut key words go to this file and delete all data in this file
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'm trying to use vi mode in bash. via the .inputrc (on OSX):
set editing-mode vi
In vi insert mode, the right arrow key moves the cursor to the right, but it stops on the last character in the line. If the cursor is past the end of the line, it moves the cursor to the left. So, in sum, the farthest right you can go is to the last character in the line.
$ cd /usr/locl/bin
# Move the cursor to the middle of the line, and fix something there
$ cd /usr/local/bin
# Now move the cursor back to the end, and write a character (/)
$ cd /usr/local/bi/n
As shown above this means you cannot edit the end of the line without going into command mode (and using 'a').
I found an article which seems to indicate the version of readline/bash might be the problem. However I used brew to upgrade bash (GNU bash, version 4.3.42), and even tried to install and link readline (6.3.8), as recommend by that site. But no luck. Its possible the upgrade was done incorrectly.
This means I'm looking for one of the following:
The proper way to upgrade bash and readline in OSX terminal
A way to check the versions of bash/readline that OSX is actually using
Another fix for this bug (somehow passing in the virtualedit=onemore option in the inputrc)
Indications that the latest versions of readline might have re-introduced the bug, and solutions.
Also: if theres a similar thing with editrc
Note: I'm looking to make readline in bash act near identical to the default (for others who periodically use my terminal), but allow me to use vim mode. This means I don't need workarounds, but fixes.
Answer here: https://unix.stackexchange.com/a/222506/198846
Apparently it's a bug in the bash version shipped with OSX (3.2), it's fixed in 4.3 according to that answer. Use bash --version to check your bash version.
To fix, update bash, e.g.
macports: sudo port install bash
brew: brew install bash
Once installed bash --version will show it's updated (assuming standard brew/macports paths at the start of your $PATH)
You then have to change your default login shell (in System Preferences->Users & Groups->right click your user->advanced options->login shell) to the path of the new bash:
(default) macports: /opt/local/bin/bash
(default) brew: /usr/local/bin/bash
Changing the default login shell step is required even if which bash shows the macports/brew one.
All credit to the answer linked above.
Can't you edit .bashrc itself instead to use vi mode? The command set -o vi does it in my case (you are in edit mode initially). Also remove the .inputrc edit as the two may actually interact nefariously afterwards.
I figured out recently that my '~' character doesn't work in gnome-terminal:
-it works in ANY application I can run (sublime text, emacs, gedit, nano...)
-it works on TTYs (ctrl+alt+FX)
-it works on xterm, xfce4-terminal etc.
-it doesn't work in gnome-terminal. I reinstalled it, still doesn't work
-it doesn't work in dash, when launched from gnome-terminal
I use zsh, I tried to launch it with a brand new .zshrc since I have quite a lot of keybindings in it and it still doesn't work.
Oh, and also, when I run 'sed -n l' and try a '~', nothing shows up, so no key binding from anywhere, I guess...
I'm kind of out of ideas right now, and hope you could help me?
Regards
If other terminals in the same X session are seeing the keypress and things running in gnome-terminal are the only things that can't then gnome-terminal is grabbing the keypress.
You can confirm this by running read -n 1 in gnome-terminal and hitting ~. If you get the prompt back then the shell saw it. If you don't it didn't.
If it doesn't then you need to see what in gnome-terminal is grabbing it. Check the shortcuts listed in the menus first.
In my quest to configure my shell to work exactly how I want it with respect to the alt/meta key I am having some trouble. Recently I added "bindkey -m" to my .zshrc and now whenever I start a zsh shell (ie open a terminal window) I get this error "warning: `bindkey -m' disables multibyte support".
Now since I don't care much about multibyte support atm, is there a way I can disable just this warning? Even better would be a way to use 8th-bit meta as well as multibyte. Also note that this happens on a clean zsh install on 4.3.9 and 4.3.10
My reasoning for wanting bindkey -m
vim: alt mappings (my own personal commands/mappings)
zsh: alt mappings (such as Alt-. to recall the last argument of the previous command)
emacs: alt mappings (lots of built-ins)
So, is there any way to disable this warning or otherwise accomplish what I'm trying to do?
You can sweep the message under the rug:
bindkey -m 2>/dev/null
Don't mappings to escape (\[) also work for Alt for you? Alt-. works for me, for example, by default.
Also, unless you're talking about the command line editing modes, vim and emacs handle their own keyboard mapping. Settings in zsh won't affect them.