In all GUI text editors, web browsers and IDE’s you can move a cursor:
- left/right arrows - move by char;
- ctrl+left/right - move by word;
- home/end - move to start/end of line.
Add Shift to any of above combination and everything you jumped through now is selected and you can: Ctrl+C, Ctrl+X,Delete to copy/cut/delete selection.
Also, you can Ctrl+Delete and Ctrl+Backspace to delete a next/previous word.
Also, you can Ctrl+Home/End to jump to start of first line or end of last line.
I want this to work when I type in a command in my Terminal.
Is it possible in Linux? It’s a vanilla experience in Windows+Powershell, thanks to default PSReadlLine extension. It works both in conhost.exe and in Windows Terminal, but doesn’t work in WT + cmd.exe, which makes me think it’s PSReadLine which is responsible for this technological perfection.
“But you can’t copy with Ctrl+C, it’s…” - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.
I’m not bound to any distro or terminal application, but right now I don’t see these incredible text editing techniques working even in Ubuntu+Powershell+PSReadLine, to say nothing about the Bash. I’ve tried installing WezTerm, but it doesn’t have text selection either, at least by default. And I’m inclined to think it has nothing to do with terminal emulators at all, since it works in conhost.exe+Powershell.
I think this is one of many un-features in Linux world where
- It would benefit a beginner
- It sounds simple but actually quite complicated to get right (especially if you aim to keep compatibility with things)
- Anyone possessing the skills to implement it neither needs it nor cares about it
As such, for you individually, I suggest just getting more comfortable with tmux (or zellij) and vi-like keybinds for text manipulation. Once you learn those (and set your readline mode to
vi), you won’t look back. Oh, also, tryCtrl+x Ctrl+ein bash, it might help.Or switch to emacs and using it as a terminal emulator. In that case you will have to learn and use emacs keybindings, but the selection semantics in the “terminal” will be the same as in the “editor”.
one of many un-features in Linux
What exactly? Shift-selection is already possible with Blesh. I think I’ve seen scripts for synchronizing buffer with clipboard. And everything else is a matter of redefining existing shortcuts.
I’ve heard about Linux being highly customizable and decentralized OS, and suddenly I can’t define my own shortcuts because there is a list of un-features?
I don’t care about Vi and Emacs, I already have my workflow and I’m trying to transfer it to Linux. When I will succeed, then (maybe) I will spend some time to explore other ways of interacting with terminal. Otherwise, it’s not freedom, it’s becoming a victim of OS.
I’ve heard about Linux being highly customizable and decentralized OS, and suddenly I can’t define my own shortcuts because there is a list of un-features?
You can customize it to do whatever you want. Heck, you can write your own terminal emulator that does exactly what you need. But some things can be harder to do than others and require skills and experience. Once someone implements those harder things, they become a “feature”. Before then, therefore, they are an “un-feature”. See https://xkcd.com/1349/
E.g. it is probably possible to set up your shell to use shift-selection for the command you’re currently editing, but shift-selection for the output of a previous command will require terminal support. You will have to make sure that the two don’t interfere with each other, which can be quite complicated.
I already have my workflow and I’m trying to transfer it to Linux
Linux is a different OS that, by default, does things differently from others. You can configure it to emulate some other UX, but it won’t necessarily be easy. In the meantime, you can install the
microeditor, setEDITOR=micro, and then Ctrl+x Ctrl+e in bash to edit the command in a more familiar setting.I’m fine, I got what I wanted. Apparently, it isn’t un-feature of Linux, it’s un-feature of ReadLine which is shipped with Bash.
I’ve got what I wanted with wezterm + powershell. I can edit my commands the same way I edit any text anywhere in the system, both in Windows and Linux, and I can copy-paste back and forth between terminal and any other app. This is awesome. This is freedom. This is UX done right.
I will paste below some observations I’ve made.
Possible solutions for Bash
- https://github.com/jirutka/zsh-shift-select - plugin for zsh as pointed out by @stupid_asshole69@hexbear.net and several other sources;
- https://github.com/akinomyoga/ble.sh - ReadLine replacement for Bash (most promising);
- https://github.com/magenta404/natural-selection - plugin for FishShell;
- https://www.reddit.com/r/pop_os/comments/p0jjno/how_to_use_shift_arrow_keys_to_select_text_in/ - most useful source on this topic.
Blesh
https://github.com/akinomyoga/ble.sh/wiki/Manual-§4-Editing
- Super simple installation.
- Home/End - Jump to start/end as expected. ✅
- Ctrl+Backspace removes left char instead of left word. ❌
- Ctrl+Delete removes next word as it should. ✅
- Shift+arrows - char-wise text selection ✅
- Shift+Ctrl+arrows - word-wise text selection ✅
- Shift+Home/End don’t do anything. ❌
- Backspace/Delete: When smth is selected they delete it. ✅
- Copy/Paste/Cut: ❌
- It’s Alt+W/Ctrl+Y/Ctrl+W instead of Ctrl+C/Ctrl+V/Ctrl+X.
- All work with selection as expected.
- All work with internal buffer instead of system clipboard.
- System clipboard:
- Can’t copy selection to clipboard, can’t paste clipboard into selection.
- Ctrl+Shift+C/V work as they do in vanilla bash: copy what is selected with mouse to clipboard, paste from clipboard.
- Ctrl+C prints current command and starts new one like in vanilla bash.
zsh-shift-select
- Stated to have best compatibiliy with Alacritty.
- Alacritty requires Cargo (440MB).
cannot install package alacritty 0.16.1, it requires rustc 1.85.0 or newer, while the currently active rustc version is 1.75.0Fail. Will use Gnome Terminal instead.
- Alacritty requires Cargo (440MB).
- Needs zsh, super simple installation.
- Zsh should be default shell,
gnome-shell crashed with SIGSEGV. - Plugin itself has simple installation, just git clone .zsh file and source it in
.zshrc
- Zsh should be default shell,
- Ctrl+arrows - prints CD instead of moving word-wise ❌
- Ctrl+Backspace, Ctrl+Delete - are not deleting left/right word ❌
- Home/End - Jump to start/end as expected. ✅
- Shift+Left/Right - char-wise text selection ✅
- Shift+Ctrl+arrows - word-wise text selection ✅
- Shift+Home/End don’t do anything. ❌
- Shift+Up/Down - Select one line up/down ✅
- Backspace/Delete - When smth is selected - delete it. ✅
- Copy/Paste/Cut: ❌
- Documented as Alt+W/Ctrl+Y/Ctrl+W instead of Ctrl+C/Ctrl+V/Ctrl+X.
- Alt+W/Ctrl+Y work as copy/paste.
- Ctrl+W removes previous word instead of Cut selection.
- Work with internal buffer instead of system clipboard.
- System clipboard:
- Ctrl+Shift+C/V work as they do in blesh and vanilla bash.
- Can’t copy selection to clipboard, can’t paste clipboard into selection.
- Ctrl+C prints current command and starts new one like in vanilla bash.
wezterm + Powershell
PSReadLine starts with EditMode = Emacs by default.
Set-PSReadLineOption -EditMode WindowsFixes Ctrl+arrows, Ctrl+backspace, Shift+Ctrl+arrows.Set-PSReadLineKeyHandler -Chord Ctrl+Delete -Function KillWord- Fixes Ctrl+Delete.Set-PSReadLineKeyHandler -Chord Ctrl+o -Function AddLine- allows Ctrl+o instead of Shift+Enter to create a new line without trying to execute. Shift+Enter is not possible in Linux.Reassigning Shift+Home/End in Gnome Terminal from scrolling viewport to something else is a rabbit hole, so I switched to wezterm, which fixed Shift+Home/End, and apparently also fixed a bug of Shift+arrows printing
D;D;D;instead of selecting. But broke Shift+Ctrl+arrows. But you can fix it back by disabling this assignment in lua config.Ctrl+C/V/X work fine, but without system clipboard synchronization. To fix it, install xclip. If it makes terminal freeze on Ctrl+C/X, update PSReadLine module.
- Ctrl+arrows ✅
- Ctrl+Backspace, Ctrl+Delete ✅
- Home/End ✅
- Shift+Left/Right ✅
- Shift+Ctrl+arrows ✅
- Shift+Home/End ✅
- Shift+Up/Down ❌
- Shift+Enter - Ctrl+o instead ✅
- Ctrl+C,Ctrl+V,Ctrl+X - Flawless ✅
Windows + conhost + Powershell Core
PSReadLine starts with EditMode = Windows by default.
- Ctrl+arrows ✅
- Ctrl+Backspace, Ctrl+Delete ✅
- Home/End ✅
- Shift+Left/Right ✅
- Shift+Ctrl+arrows ✅
- Shift+Home/End ✅
- Shift+Up/Down ❌
- Shift+Enter ✅
- Esc - clear current command ✅
- Ctrl+C,Ctrl+V,Ctrl+X - Flawless, all with system clipboard. ✅
Any particular recommendation?
For Bash - try blesh, it will enable some of common controls by default, and probably you will be able to manually enable other shortcuts. PSReadLine is calling
xclipeach time for copy/paste action for clipboard sync, probably it will be possible with Blesh too.
I think if we want something like that to be consistent everywhere we need to stop using Ctrl so much as a modifier for non-terminal tasks. It doesn’t solve everything, but using Alt or Super for copy and paste like Haiku and MacOS do is a big step in the right direction. It’s just hard to change an established custom without making the whole experience less consistent
It’s nice to see you think of it as of movement towards consistency. I also look at it this way.
But what is it about Ctrl? Text editing is historically the main task of computers, and Ctrl is the main “modifier” key. To me it seems fair it’s dedicated for some text editing shortcuts. Probably they are consistent since 1980’s.
but ctrl-c to cancel terminal tasks predates the 1980s. the inconsistency came in when apple decided to ignore that precedent and introduce ctrl-c, ctrl-x, and ctrl-v as shortcuts in their graphical UI.
to achieve consistency, probably better to invent a new terminal type that does away with the accumulated cruft of 50 years. problem is you would also need new cli programs to go with it.
I feel your pain, the only one’s I know are…
- CTRL+a = cursor to beginning of line
- SHIFT+CTRL+c = Copy
- SHIFT+CTRL+x = Cut
- SHIFT+CTRL+v = Paste
I get those 3 bulleted features in my terminal, alacritty. But not with Shift. For highlighting I’m pretty much limited to selecting text with the mouse and ctrl-shift-c.
For more sophisticated text selection, tmux comes to mind. Default key bindings appear to be emacs-esque, though vi style is possible too. Custom keybindings are possible as well. It does seem like you may be forced to enter a special mode for selection rather than having that available all the time with just shift.
For more sophisticated text selection
Here it is. What I’m asking for is not sophisticated at all, quite the opposite. I ask for keybindings which work in almost all text editing areas, in all applications, all operating systems. Vi and eMacs are steps in opposite direction. I think I even used a vi-mode in terminal a couple of years ago. I doubt it’s possible to simplify command editing with it.
The thing is that vi and emacs have existed since long before those other new editors came around.
What you want is possible to do by configuring your
~/.inputrc(see readline manual page for details), it’s just that the defaults are different because they are from a time when many keyboards didn’t even have arrow keys (and the ones that had them were in non-standard positions) so most of the shortcuts that became standard in those days are completely different than the ones common today. Given that the terminal is meant to emulate old style DEC VT100 terminals (that’s why it’s called terminal “emulator”) it made sense to use those default that people had grown used to.Personally, I’ve grown used to Ctrl+a, Ctrl+k, Ctrl+w, Ctrl+e and Ctrl+y …I dont have to reach to wherever the Home key is in whatever keyboard I happen to be using at the moment (specially with modern 75%/60%-sized keyboards today). Or use a combination that also requires shift and having to hold so many keys together. In fact I went the opposite direction and customized my Powershell profile while I’m on windows to keep many of those old shortcuts in the Windows pwsh terminal as well.
This is one of the reasons I prefer using ctrl-insert/shift-insert when it’s available. Unfortunately the Insert key seems to have disappeared from a lot of keyboards. Scroll lock sometimes works instead of ctrl-s and ctrl-q. I would be ok remapping ctrl-c to ctrl-break, but I still use ctrl-z to background a job. Would be great if terminals had a quick easy way to select your preference of Microsoft, unix, or CUA shortcuts.
“But you can’t copy with Ctrl+C, it’s…” - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.
What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected? In every one I’ve ever used, ctrl-c still sends SIGINT even with text selected (and one must must use ctrl-shift-C/ctrl-shift-V to copy/paste).
I don’t have any suggestion for getting the behavior you’re asking for, but besides the normal ctrl-(shift)-C/V clipboard FYI you also have two other types of clipboard-like things: one which works anywhere (not only in the terminal) and is actually always automatically copying anything you select and lets you paste from it with middle click (this originated with X Windows but i think most Wayland compositors have also implemented it by now), and another which is found in GNU Readline (used by bash and numerous other REPLs) called the “kill buffer” which can be pasted (or “yanked”) from and cut (or “killed”) to using Emacs keyboard shortcuts (which also include various cursor movement controls).
Notes:
- the kill buffer is local to a given readline context, it’s not shared across different shell windows.
- the list of emacs keybindings in that wikipedia article i linked is currently confusingly referring to the kill buffer as “the clipboard”
- you can drastically reconfigure your readline keybindings and other behavior by editing your
.inputrcfile, but you cannot achieve what you were originally asking for because there is no concept of text selection in readline.
HTH!
What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?
I know that the terminal emulator built into the JetBrains IDEs works that way…
What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?
This is what I experienced in conhost.exe (legacy windows console experience, predecessor of Windows Terminal) + Powershell. In windows terminal it works this way too. This is why I suspect it’s related not to terminal itself (conhost.exe/wt.exe/gnome terminal etc), and not to specific shell (bash/powershell), but to an extension for shell (ReadLine,PSReadLine).
As for various types of buffers and clipboards, I always felt like one system-wide clipboard with clipboard history is enough. When I cut something from terminal, quite often I paste it into another app, and not back to terminal.
I would just like my inputs to be separate from the outputs. Anyone write a split pane thing?
I think most of this works for me in zsh. But also tmux can help with selection; I believe by default you use your prefix then open bracket (
Ctrl-b + [) to put your self in selection mode. I have some configs to use vim bindings in selection mode.Tmux selection:
# Yanking bind-key -T copy-mode-vi v send-keys -X begin-selection bind-key -T copy-mode-vi C-v send-keys -X rectangle-toggle bind-key -T copy-mode-vi y send-keys -X copy-selection-and-cancelzsh keybinding:
# Key Bindings # set vim mode bindkey -v # create a zkbd compatible hash; # to add other keys to this hash, see: man 5 terminfo typeset -g -A key key[Home]="${terminfo[khome]}" key[End]="${terminfo[kend]}" key[Insert]="${terminfo[kich1]}" key[Backspace]="${terminfo[kbs]}" key[Delete]="${terminfo[kdch1]}" key[Up]="${terminfo[kcuu1]}" key[Down]="${terminfo[kcud1]}" key[Left]="${terminfo[kcub1]}" key[Right]="${terminfo[kcuf1]}" key[PageUp]="${terminfo[kpp]}" key[PageDown]="${terminfo[knp]}" key[Shift-Tab]="${terminfo[kcbt]}" # setup key accordingly [[ -n "${key[Home]}" ]] && bindkey -- "${key[Home]}" beginning-of-line [[ -n "${key[End]}" ]] && bindkey -- "${key[End]}" end-of-line [[ -n "${key[Insert]}" ]] && bindkey -- "${key[Insert]}" overwrite-mode [[ -n "${key[Backspace]}" ]] && bindkey -- "${key[Backspace]}" backward-delete-char [[ -n "${key[Delete]}" ]] && bindkey -- "${key[Delete]}" delete-char [[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-history [[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-history [[ -n "${key[Left]}" ]] && bindkey -- "${key[Left]}" backward-char [[ -n "${key[Right]}" ]] && bindkey -- "${key[Right]}" forward-char [[ -n "${key[PageUp]}" ]] && bindkey -- "${key[PageUp]}" beginning-of-buffer-or-history [[ -n "${key[PageDown]}" ]] && bindkey -- "${key[PageDown]}" end-of-buffer-or-history [[ -n "${key[Shift-Tab]}" ]] && bindkey -- "${key[Shift-Tab]}" reverse-menu-complete # Finally, make sure the terminal is in application mode, when zle is # active. Only then are the values from $terminfo valid. if (( ${+terminfo[smkx]} && ${+terminfo[rmkx]} )); then autoload -Uz add-zle-hook-widget function zle_application_mode_start { echoti smkx } function zle_application_mode_stop { echoti rmkx } add-zle-hook-widget -Uz zle-line-init zle_application_mode_start add-zle-hook-widget -Uz zle-line-finish zle_application_mode_stop fi # History - use current line up to cursor to search through history with arrow keys autoload -Uz up-line-or-beginning-search down-line-or-beginning-search zle -N up-line-or-beginning-search zle -N down-line-or-beginning-search [[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-beginning-search [[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-beginning-searchSame, I have most of those, but selection with shift
Bash shell uses readline for this, which I would guess is the namesake of PSReadLine:
https://wiki.archlinux.org/title/Readline
https://man.archlinux.org/man/readline.3#DEFAULT_KEY_BINDINGS





