Problem steps like this:
copy text 'kill-server' to system clipboard
hit Prefix : to enter the tmux command prompt
hit command+v to paste
The result paste text is 200~kill-server201~ instead of kill-server. This weird bracketed paste mode text do not happen in shell prompt but in tmux command prompt, and I had tried to turn off bracketed paste mode but without luck.
Environment that has this issue:
Mac OS 10.11.1, iTerm, zsh 5.0.7, Tmux 2.1
Mac OS 10.10.1, iTerm, zsh 5.1.1, Tmux 1.9
Environment that without this issue:
Mac OS 10.11.1, iTerm, bash, Tmux 2.1
I'm posting this as an answer because it's a bit too long and I need some formatting... So here it goes.
I can reproduce only with zsh 5.1+. There's no reason to expect the problem on 5.0.x, because bracketed paste mode was introduced in 5.1. You might be doing something wrong in your testing, or there might be something peculiar about your setup, in which case you have to explain better. Also, iTerm2 probably doesn't play any part in this, since I could reproduce in Terminal.app just fine (of course they could both have the same defect...).
Considering bracketed paste mode is a ZLE feature, I think (disclaimer: the rest of this paragraph is purely my speculation) the real problem is that tmux uses the underlying shell's line editing features (ZLE, in zsh's case) in its command prompt to offer better editing experience (for instance, you have access to all the Emacs style shortcuts there), but its command prompt is a dumb term, and doesn't understand the bracketed paste sequences. So we have this weird situation of two modes of terminal emulation within tmux, one is fairly smart which happens within each pane, and the other is dumb which happens in its command prompt.
Solutions and workarounds:
This is probably worth reporting to tmux. https://github.com/tmux/tmux/issues.
Turn off ZLE bracketed paste. It does work, you're probably doing it wrong. If you don't mind losing bracketed paste in tmux, you could put the following somewhere in your shell init sequence:
(( $+TMUX )) && unset zle_bracketed_paste
In iTerm2, you have access to advanced paste (Edit->Paste Special->Advanced Paste..., or ⌥⌘V). Just uncheck "Bracketed paste mode", and you shouldn't see the escape sequences.
I solved this problem finally just deactivated the safe-paste plugin in my oh-my-zsh.
The safe-paste used to fix zsh up arrow completion issue. But now, the arrow completion issue is gone while inducing tmux bracketed paste problem. I haven't dived into the code of safe-paste yet. Hope to help others encountering the same problem.
Related
Can I use zsh vi normal mode to move around previous commands output or the printed text in the shell to copy/yank it ?
For example in the screenshot below. I want to move to the output of ls to copy something. When I press j/k zsh cycle my command history but doesn't move up to the printed text. j/k move one line down/up only when I have multiple line command that I'm currently writing but haven't executed yet.
To the best of my knowledge, the ability to access the output of commands interactively is the domain of your terminal (-emulator), not the shell. You would use commands like sed, awk, grep, possibly in a pipe, to access, manipulate and use output you know in advance is the part you are interested in.
To access the output with keyboard shortcuts/command-keys, I suggest using the like of tmux - it allows to copy/yank from the whole terminal display as if it was a text-file in an editor.
I use zsh and I would like backward-kill-word in Emacs mode to behave like Emacs (and bash, fwiw). The behaviour that I have failed to reproduce is that when I press multiple backward-kill-word Emacs adds the killed text to the cut buffer (the first item in the killring) making it possible for me to yank everything with one yank command.
How can I configure zsh to behave like this aspect of Emacs editors?
Actually, by default, Zsh's cut buffer works exactly the same as in Emacs. Just use zsh -f to start Zsh without config files and try it.
However, are you perhaps using zsh-autosuggestions or zsh-syntax-highlighting? There are bugs in these plugins that break this feature:
https://github.com/zsh-users/zsh-autosuggestions/issues/363
https://github.com/zsh-users/zsh-syntax-highlighting/issues/150#issuecomment-658381485
Fixes have been submitted, but for zsh-autosuggestions, none have yet been merged, and for zsh-syntax-highlighting, the fix won't work until Zsh 5.9 has been released.
In the meantime, though, zsh-autocomplete contains a workaround that fixes the problem. If you add that plugin, your cut buffer will start functioning like normal again.
I am using the zsh shell on my mac.
However my when I type Ctrl-A and Ctrl-E I am getting the characters on the screen instead of moving to beginning or the end of the line.
ps -ef ^A^E^A^E
How can I fix this? Thanks
Nvm found a solution, it was a problem with my keybindings.
I was using preztro and set the editor binding to vim whereas it was set to emacs in zsh
I'm new to Vim. I was experimenting with vim-powerline and tmux (and pathogen and vundle).
Somwehere in that process I tried to remove powerline and tmux started receiving this error.
My .tmux.conf file is empty. How can I find where tmux is trying to run this command?
I had this problem, too, but not in the first tmux window. It only happened for me in subsequent windows. I found a solution, but not exactly the cause of the problem.
The short version is the set the value of the POWERLINE_COMMAND variable in your .bashrc on the line before you source the bash binding. For me, that means:
export POWERLINE_COMMAND="$HOME/powerline/scripts/powerline"
. $HOME/powerline/powerline/bindings/bash/powerline.sh
I don't get exactly why this happens in subsequent tmux windows but I added some echo lines to the bash binding to find out what's happening. When the binding is sourced in subsequent windows, POWERLINE_COMMAND is already set to powerline, so it skips the code that checks for the right place to set it. I couldn't figure out where, how, or why it's already set, though.
Here's the code that does the check from the beginning of the bash binding:
if test -z "${POWERLINE_COMMAND}" ; then
if which powerline-client &>/dev/null ; then
export POWERLINE_COMMAND=powerline-client
elif which powerline &>/dev/null ; then
export POWERLINE_COMMAND=powerline
else
# `$0` is set to `-bash` when using SSH so that won't work
export POWERLINE_COMMAND="$(dirname "$BASH_SOURCE")/../../../scripts/powerline"
fi
fi
Since it works in the first window, I just set POWERLINE_COMMAND to point to the command that it points at in the first window. Setting it before sourcing the bash binding skips the whole check.
I suggest you to check your shell's configuration files. If you use e.g. use bash, check $HOME/.{bashrc,profile} or $HOME/.zshrc for zsh. There is probably a line like
. {repository_root}/powerline/bindings/bash/powerline.sh
according to the powerline installation instructions.
This question is about configuring the R console to behave like a bash shell when it comes to navigating the command history. It is somewhat related to the ?history. For brace-enclosed multi-lines, I'd like to configure the command history navigation of R to be similar to bash.
Presently when running R in an xterm under Linux, using the up-arrow to navigate the command history causes each previous line to be recalled one by one, even if a set of lines had been enclosed in braces. This occurs, for example, when copy/pasting a multi-line function from a text editor into the R console. Not so with bash.
Here is an example of how bash functions in this regard:
In a bash shell within an xterm under Linux, after typing the following five lines...
a=1
{
x=1
y=1
}
... the first press of the up-arrow will recall a single line reformulation of the brace-enclosed commands, like this ...
{ x=1; y=1; }
... and the second press will recall this ...
a=1
It seems that in R, the up-arrow navigates backwards one line at a time, regardless of encapsulation. Is there a way to configure R so that it's command history navigation functions like bash's?
You could use rlwrap. I use it for other console programs and it works very well. You will need to prepend the R command with the rlwrap binary and then your history lines can be restored in a number of ways, including multi-line matching.
Workaround for Linux/Unix
Similarly as in Rstudio (thanks to Ari B. Friedman comment), where user in R console is using ShiftEnter to bypass RETURN, you can start newline (in R terminal) without accepting newline command using Ctrl-VCtrl-J. This way the multi-line command will be accepted into history as one-liner with line-feeds instead of enters and you will even have the chance to edit it. You can even manage in your .inputrc file to have custom combination for this action.
I do not think direct reconfiguration of R is possible.
Readline man page may help more.