Jaunty: CTRL-LEFT and CTRL-RIGHT do not work in zsh

Bug #355883 reported by Bernhard on 2009-04-05
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Gnome Virtual Terminal Emulator
bash (Ubuntu)
mksh (Ubuntu)
Thorsten Glaser
vte (Ubuntu)
Ubuntu Desktop Bugs
xterm (Ubuntu)
zsh (Ubuntu)

Bug Description

In jaunty the key combinations CTRL-LEFT and CTRL-RIGHT do not work in gnome-terminal anymore if I use the zsh shell. Is it possible to map the key CTRL-LEFT to ESC-b and CTRL-RIGHT to ESC-f? If such a keybinding would exist in either xterm or gnome-terminal, that would probly solve the problem.

If I remember correctly, such a keybinding did exist in intrepid.

Bernhard (b.a.koenig) wrote :

I have also filed a bug here: http://bugzilla.gnome.org/show_bug.cgi?id=578045
But not sure if it's GNOME related, so I preferred to post another bug here, especially because it seems to be a new problem in jaunty (at least for me).

affects: ubuntu → zsh (Ubuntu)

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: zsh 4.3.9-4ubuntu1
PackageArchitecture: i386
 PATH=(custom, user)
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Bernhard (b.a.koenig) wrote :

I can confirm this with various shells (dash, bash and mksh):

$ dash
$ ^[[1;3D^[[1;3C
$ mksh
$ ;3D;3C
$ bash
$ DC

Bernhard (b.a.koenig) wrote :

Not a dup of bug 104708, at least not for me. As I said in the description, this problem shows up in zsh but not in bash (at least for me). Also it is a new issue in Jaunty (worked in intrepid), so it's not a duplicate of bug 104708.

Bernhard (b.a.koenig) wrote :

@matthias: in some cases you can fix it by adding keybindings to your rc file. E.g. if you add

setopt emacs

to your .zshrc, that should give you emacs keybindings. That worked for me in intrepid but it doesn't work anymore in jaunty. That's why I think it's a new problem.

Thorsten Glaser (mirabilos) wrote :

I am mksh upstream.

This is not fixable with the current code, where keybindings are a præfix
(Esc, Esc [, ^X) plus one character plus an optional tilde.

While the input line editing code as a whole deserves overhaul, it has
fairly low priority, so this is WONTFIX for mksh.

Please use Esc+b and Esc+f instead (or bind it to other keys which
generate a “short enough” sequence), or tell your terminal emulator
to map Ctrl-Left and Ctrl-Right to Esc+b and Esc+f, respectively.


$ cat /etc/inputrc
$if mode=emacs

It's simple strange that it worked for under Debian sid until installed Ubuntu yesterday.

Changed in mksh (Ubuntu):
assignee: nobody → mirabilos
status: New → Confirmed
Bernhard (b.a.koenig) wrote :

Yes I have this in my /cat/inputrc (in jaunty)

# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

$if term=rxvt
"\e[8~": end-of-line
"\eOc": forward-word
"\eOd": backward-word

But it CTRL-LEFT works for me in bash (in xterm or gnome-terminal doesn't matter). But once I switch to zsh, then it doesn't work anymore.

Bernhard (b.a.koenig) wrote :

@Thorsten: so you are saying that this is not fixable in the shells themselves. But I am pretty sure that this thing worked in intrepid where I was always using the gnome-terminal as emulator. So then it's a bug in gnome-terminal? Problem is I cannot find these exact keybindings in "Edit" "Keyboard shortcuts".

Bernhard (b.a.koenig) wrote :

OK, then I'll try to rephrase the bug. I'll make a wish for the packages xterm and gnome-terminal to map CTRL-LEFT and CTRL-RIGHT to ESC-b and ESC-f (in gnome-terminal, ALT-b and ALT-f works as well).

affects: dash (Ubuntu) → gnome-terminal (Ubuntu)
Changed in bash (Ubuntu):
status: New → Invalid
Changed in zsh (Ubuntu):
status: New → Invalid
Bernhard (b.a.koenig) on 2009-04-09
description: updated
tags: added: binding key xterm
Thorsten Glaser (mirabilos) wrote :

>@Thorsten: so you are saying that this is not fixable in the shells themselves.

in mksh only – I’m mksh upstream, I have no relation to the other shells listed.
Please set the bug for mksh only to WONTFIX, because while it’s on the TODO
it’d require a rewrite of the keybinding and input processing code.

>ALT-b and ALT-f works as well

Note that it won’t if your Alt key produces Meta (then Alt-b = â and Alt-f = æ).
But I hope you can live with that (in mksh) for a while.

There's no WONTFIX, so I've set it to invalid, because in mksh it is a desired behaviour.

Changed in mksh (Ubuntu):
status: Confirmed → Invalid
Bernhard (b.a.koenig) wrote :

Btw, for those that are interested: I'm using zsh and the following lines in .zshrc fixed it for me

bindkey ";5C" forward-word
bindkey ";5D" backward-word

it does make a beep on jumps though, but you can switch off system beep in zsh with "no_beep".

affects: gnome-terminal (Ubuntu) → vte (Ubuntu)
Changed in vte (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
status: New → Triaged

On Sat, 11 Apr 2009, Matthias-Christian Ott wrote:

> There's no WONTFIX, so I've set it to invalid, because in mksh it is a

Hm, actually, there is, but we cannot see it, according to the LP docs.

> desired behaviour.

Not actually desired, but not fixable with the current codebase.

> If I remember correctly, such a keybinding did exist in intrepid.

Interesting. Konsole on Hardy doesn’t, though.

Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Changed in vte:
status: Unknown → New
Thomas Dickey (dickey-his) wrote :

Regarding comment #11 and following - xterm is configurable.
I suggest that he read the documentation and customize it.
(This is not even a wishlist item, since it's a problem with
the user's understanding of the program).

Bernhard (b.a.koenig) wrote :

@Thomas: I have since configured my terminal via shell settings. The desired behaviour should be default though, especially for "out-of-the-box" Ubuntu.

Thomas Dickey (dickey-his) wrote :

On Thu, 30 Jul 2009, Bernhard wrote:

> @Thomas: I have since configured my terminal via shell settings. The
> desired behaviour should be default though, especially for "out-of-the-
> box" Ubuntu.

Doing that would break existing applications (those that use
the terminal description from ncurses and xterm, for example),
and would introduce sequences which correspond to those already
sent by other combinations. (It's likely that some other users
of Ubuntu would object to this).

Thomas E. Dickey

Bernhard (b.a.koenig) wrote :

The reason I filed the bug is that this key combination did work by default in intrepid (after installing zsh) but did not work by default anymore in jaunty. Unfortunately, there are so many different vte settings in the different shells that I never saw through the reason why it stopped working in jaunty.

Thomas Dickey (dickey-his) wrote :

Near the end of this section, there's a table showing the codes sent by xterm for different modifiers:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#PC-Style Function Keys
Back to the original report -

A "3" is sent for an "alt" key, a "5" for a control key.
That's not changed in upstream xterm, isn't likely to.
But the report says a "3" is sent with a control key.

However, gnome-terminal has changed several times.
None of this is documented except in bug reports.

For instance, at one point gnome-terminal set its keys based on a termcap entry.
That didn't work well since the termcap entry lacked information on the control/cursor-keys.
As I recall, they "fixed" the problem by hardcoding in some behavior.
But in doing so, they neglected to bother to make it compatible.

The (unresolved) problems with gnome-terminal are technically solvable.
For instance, xterm has an option (-kt tcap) which tells it to read the "termcap".
But if it is linked with ncurses, it reads the extended information that describes these keys.
(If the terminfo doesn't describe the key, xterm's free to use its builtin behavior of course).

Bryce Harrington (bryce) on 2009-09-02
tags: added: jaunty
Pierre Chef (pierre.chef) wrote :

i have added to my .zshrc
bindkey "^[[1;5C" forward-word
bindkey "^[[1;5D" backward-word

to know what your key codes are,
cat > /dev/null
and press the shortcuts you want

Thorsten Glaser (mirabilos) wrote :

Fixed upstream in commitid 1004AB6650915B0514A – see http://cvs.mirbsd.de/mksh/

Will be in mksh R40 – see http://mirbsd.de/mksh#clog (or http://mirbsd.de/mksh#r40 once it’s out)

Changed in mksh (Ubuntu):
status: Invalid → In Progress
Thorsten Glaser (mirabilos) wrote :

Hm, this status is more right. ☺

Anyway, I will (probably) only support the (as confirmed by Tom Dickey) “correct” sequence
for Ctrl-Cur{Left,Right}, the ones with a ‘5’ in them, not the ones with a ‘3’ in them (Alt-{←,→}).

Changed in mksh (Ubuntu):
status: In Progress → Fix Committed
Thorsten Glaser (mirabilos) wrote :


Sorry, there won’t be an mksh R40 release in time for karmic…
the above mentioned one does not include the code change,
which is a little too intrusive for a _really_ quick backport and
has not yet received much testing.

Bryce Harrington (bryce) wrote :

As per comments, this is a configuration option and not one to be set as default in ubuntu.

Changed in xterm (Ubuntu):
status: New → Won't Fix
Launchpad Janitor (janitor) wrote :
Download full text (11.1 KiB)

This bug was fixed in the package mksh - 39.3-1ubuntu1

mksh (39.3-1ubuntu1) lucid; urgency=low

  * Merge from Debian unstable. (Closes LP: #529559)
    New upstream version. (Closes LP: #355883)
    This integrates a workaround for a gcc bug. (cf. LP: #375604)
    Remaining Ubuntu changes:
    - debian/control, debian/rules: Exclude dietlibc on powerpc/ppc64
      and sparc (cf. LP: #381332)
    - debian/README.Debian, debian/mksh.postinst: Hardcode installing
      mksh as /bin/sh to false (cf. LP: #348872) but retain debconf
      infrastructure so that, if set to true in old installations, it
      will correctly be removed on upgrade

mksh (39.3-1) unstable; urgency=low

  * New upstream version R39c; shortened ChangeLog since R39:
    - [tg] Build system, code, docs and testsuite cleanup, also style(9)
    - [tg] Parse and evaluate ${parameter op word} correctly
    - [tg] Fix possible SIGSEGV in interactive mode bind builtin due to
      mis-optimisation of gcc combined with a bogus prototype;
      discovered by Grml.org's Frank Terbeck (ft), thanks!
    - [tg] Clean up some more strict *roff or compiler warnings: dashes,
      undefined macros; casting errors (constness, signedness, type
      width/class) and catch possibly unaligned pointer dereferences
      early; remove code/rodata redundancies, plug memory leaks
    - [smultron] Tweak the manual page: point out the word “colour”
    - [tg] Optimise dot.mkshrc DJB’s CDB hash implementations; add Bob
      Jenkins’ one-at-a-time hash (standard and leading-bit
      initialised); fix signedness in expressions; let the hashes use
      stdin if "$*" is empty, like Lb64{en,de}code; use
      “[[ -o utf8-mode ]]” ipv “[[ $- = *U* ]]”
    - [tg] Build.sh portability fixes: missing prerequisite headers;
      ensure $CC is never called without $CFLAGS; fix test.sh, et al.
    - [tg] Optimise internal variable representation; use one-at-a-time
      hash; cache hash values for faster resizing at zero memory cost;
      clean up hash table (keytab) code; switch hash table collision
      resolution algorithm to Python’s; prepare for later changes
    - [tg] Fix type errors in the source code (int → bool, size_t,
    - [tg] Fix “${foo:bar:$baz}” not working (missing substitute() call)
    - [tg] Implement “typeset ±a” as nop
    - [tg] Support ksh93-like “${!foo[@]}” listing the keys (indicēs) of
      all set array elements
    - [tg] Support bash/ksh93-like “array=([key]=value …)” and
      (additionally) “set ±A array -- [key]=value …” to directly
      specify indicēs to use
    - [tg] Document the optional, unsupported, printf(1) builtin in TFM
    - [tg] Replace realpath(3) dependency and internally used
      get_phys_path() pdksh code with own implementation; always offer
      the realpath builtin
    - [tg] Implement nameref='typeset -n' (bounded variables) like AT&T
      ksh93 but with mksh-style nested/dynamic scoping and on-use
      resolving; they cannot currently be stored in an array though
    - [tg] Add “chdir” builtin doing the same as “cd” special builtin
    - [tg, David Korn] Document more differences between mksh (and

Changed in mksh (Ubuntu):
status: Fix Committed → Fix Released

Bernhard said that putting this in one's .zshrc would be a workaround:

bindkey ";5C" forward-word
bindkey ";5D" backward-word

This did not work for me, but the following does work (since for some reason ";" is not being output):

bindkey "5C" forward-word
bindkey "5D" backward-word

Changed in vte:
importance: Unknown → Medium
Thomas Smith (tgs-resc) wrote :

I had this same problem in Lucid. @pierre.chef 's solution above worked perfectly for me. I'm using zsh under Terminator, with oh-my-zsh.

Changed in vte:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.