I recently posted a question about a strange behavior I had observed in the bash, fish and zsh shells that was not exhibited by the tcsh, csh, ksh, or dash shells. It turns out the behavior was caused by a change in the default settings of the readline library and I fixed it by adding set enable-bracketed-paste Off to my ~/.inputc.

This got me wondering. Why did this only affect that specific subset of shells on my system? Don't all shells use readline? Is there some sort of general rule? Why did bash, zsh and fish change their behavior while the other shells did not?


1 Answer 1


readline is implemented alongside bash by the same author and used by bash and among popular shells, mostly only bash.

The readline library was spawned off bash. bash 1.02's ChangeLog file has:

Wed Jun 28 16:51:42 1989  Brian Fox  (bfox at aurel)

  * New directory: LIB contains readline and history stuff,
    and is Make-able on its own.  Also contains its own

  * history.c: removed shell dependent stuff, made into standalone

Tue Jun 27 13:05:54 1989  Brian Fox  (bfox at aurel)

  * readline.c: removed shell dependent stuff.

  * New file: bashline.c contains all of the shell specific
    readline material in an attempt to begin using the
    readline stuff as a library.

Mon Jun 26 13:35:16 1989  Brian Fox  (bfox at aurel)
  * readline.c, jobs.c
     Make commands that do not complete sucessfully restore the
     tty state to whatever it was before the command was executed.

zsh used a modified version of bash's readline in it first 1.0 version in 1990 as its own line editor was not ready yet, but switched to its own in 2.0 four months later in 1991. From the README file in 1.0:

This is version v1.0 of zsh. I incorporated the GNU "readline" editor, written by Brian Fox, into the shell, just to make my life temporarily easier. I made lots of changes to it, so if there are any bugs in the editor, they're probably my fault. readline will not be a part of the next version of zsh.

Ash-based shells typically use BSD's libedit (in the case of dash it's often not enabled at compile time as dash is only intended for running scripts, not as an interactive shell).

The clone of the Unix V10 / Plan9 rc shell by Byron Rakitzis gives you a choice of line editors at compile time: GNU readline, Simmule Turner's editline and Gert-Jan Vons's vrl. The first version only offered readline. es and akanga, based on rc offer a choice of readline vs editline.

busybox has its own line editor which is used by its hush and ash based shells as well as other applets such as its bc, ed, fdisk.

readline is great in that it provides a line editor that can be (and is) used in many different tools, providing consistency but, though it's probably one of the most if not the most feature-rich general purpose line editing libraries, it is relatively limited in what you can do with it. It's also licensed under the GPL, so can only be used in software licensed under the GPL or compatible.

Most shells including ksh, pdksh and derivatives, tcsh, zsh, fish or yash have their own line-editor, often more advanced. The line editors of ksh were written circa 1983 long before bash, and that's the interface that bash's readline mostly copied. pdksh and tcsh line editors also predate bash and readline. A vi-style line editor is specified by POSIX, based on ksh's. The emacs one is not specified by POSIX as Richard Stallman (the main author of GNU emacs and incidentally also came up with the "POSIX" name) objected to it¹.

Note that there are good reasons why you would want to enable the bracketed paste mode in terminal editors or line editors that support it. See: How can I protect myself from this kind of clipboard abuse?.

¹ See "In early proposals, the KornShell-derived emacs mode of command line editing was included, even though the emacs editor itself was not. The community of emacs proponents was adamant that the full emacs editor not be standardized because they were concerned that an attempt to standardize this very powerful environment would encourage vendors to ship strictly conforming versions lacking the extensibility required by the community. The author of the original emacs program also expressed his desire to omit the program. Furthermore, there were a number of historical systems that did not include emacs, or included it without supporting it, but there were very few that did not include and support vi. The shell emacs command line editing mode was finally omitted because it became apparent that the KornShell version and the editor being distributed with the GNU system had diverged in some respects. The author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions. Although the KornShell author agreed to consider changes to bring the shell into alignment, the standard developers decided to defer specification at that time. At the time, it was assumed that convergence on an acceptable definition would occur for a subsequent draft, but that has not happened, and there appears to be no impetus to do so. In any case, implementations are free to offer additional command line editing modes based on the exact models of editors their users are most comfortable with." in the RATIONALE section of the POSIX sh specification.

  • That makes sense, thank you. And I have now seen that the change in ~/.inputrc that fixed my problem works in bash but not zsh, so presumably zsh's line editor has made the same change as readline and I would have to find the zsh equivalent fix.
    – terdon
    Feb 5, 2022 at 14:51
  • @terdon, bracketed paste was enabled in zsh in 2015 in 5.1 and was made the default from the start. bash added it in 4.4 in 2016, but not enabled by default before 5.1 in late 2020. Feb 5, 2022 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .