4

I am trying to install some key sequence bindings but I have trouble. My shell is bash, my terminal is gnome-terminal, and my system is Ubuntu 14.04 in graphic mode. Edit : my keyboard is french azerty with the numeric pad and ctrl,fn,super,alt.

Edit: a bash guide, readline chapter

I want to add contol+alt+space, but this exact sequence does not work while similar other sequences work fine. My goal is to run shell-expand-line readline but i tried upcase-word to compare.

--Let's analyze my goal's installation effect.

This is my ~/.inputrc added (ctrl+meta+space):

"\e\C- ": shell-expand-line

This is the new result of bind -p :

"\e\C-@": shell-expand-line

Of course I started a couple terminals, one before installation and one after every installation in order to compare thoroughly.

--Some experiments to ensure control+alt works in place of control+meta.

The system should emulate Meta with Alt and bash should emulate Meta with Escape, both using the byte '\033'. I tried both Alt and Esc to conclude it works fine. I tested some ctrl+meta+letter sequences to be sure.

By the way, the individual samples of Ctrl+Alt are simple : expanding an isolated tilde '~' (shell-expand-line) or changing case in random lowercase words (upcase-word) with ctrl+meta+e or ctrl+meta+v. Ctrl+meta+e is already binding to shell-expand-line so i just mixed the bindings with the useless ctrl+meta+v.

--Some more intricate observations...

I read '^@' illustrates 'NUL' character. Why this escape?

I tested xev and pressed ctrl+alt+space : the character reported is 'NUL' character.

I saw alt+space usually open the window menu of gnome-terminal while alt enables menus, of course without control key.

A conflict seems to come from the system, but I am a newbie. I just read most of the bash manual (especially readline chapter) and one forum advice about xev.

--Question

Is there more to say or to correct? Why the sequences are rewritten? How can I make my ctrl+alt+space work with bash and gnome-terminal ?

Edit : I found that '@' is transformed in 'NUL' because of a bitwise mask applied when escaping, but i do not see any reason why Alt+space gives 'NUL'.

Link-akro
  • 43
  • 1
  • 6
  • I have a temporary simple solution, I chose another similar key sequence : "\C-x\C-@" code to spell ctrl+x+space keys. It works, it is easy to press, x is near Alt and I do not need to hold ctrl+x. – Link-akro Mar 23 '15 at 08:47
  • One more workaround : **defining Meta-Space** does the trick since it is the wrong sequence sent by VTE from Ctrl+Alt+Space. But it catches the Esc+Space, what a pity. – Link-akro May 08 '15 at 15:49

2 Answers2

4

The terminal emulator (Gnome-terminal, in your case) converts key combinations like Ctrl+Alt+Space (which it receives as the Space keysym with the Ctrl and meta modifiers are) into sequences of bytes. Text characters like a and space are sent as is; keys that don't correspond to characters are sent as control characters when there is one (e.g. byte 13 = carriage return = Return, byte 9 = tabulation = Tab) and as escape sequences beginning with byte 27 = escape if there isn't. Alt+character is sent as escape followed by that character (for all intents and purposes, in typical configurations nowadays, treat “Alt” and “Meta” as synonymous — I won't go into that topic in this post). See also How do keyboard input and text output work?

Ctrl+character is sent as a control character if there is one (e.g. Ctrl+A or Ctrl+Shift+A → byte 1 = ^A). There is no control-space character, but for historical reasons, the key combination Ctrl+Space is usually transmitted as byte 0 = ^@.

You can see what key sequence the terminal sends by pressing Ctrl+V on the bash command line then the key or key combination you're interested in. Ctrl+V tells bash to insert the next character, whatever it is, instead of interpreting it as a command.

It would be logical to transmit Ctrl+Alt+Space as the two-byte sequence 27, 0 = escape, ^@. Unfortunately for you, Gnome-terminal doesn't do this, it sends 27, 32 = escape, space instead. Key sequences sent by Gnome-terminal cannot be configured (you'd need to patch the VTE library). So if you want to be able to use Ctrl+Alt+Space in the terminal, you have several possibilities:

  • Use a different terminal emulator. There are about 40 in Ubuntu.
  • Edit the source code of the VTE library to make it send a different escape sequence. You may want to suggest this as an enhancement.
  • Maybe use LD_PRELOAD to patch calls from Gnome-terminal to libvte. I haven't checked to see if it's practical, and anyway it would be cumbersome — if you care that much, use a different terminal emulator.
  • Configure your window manager or an external program to change Ctrl+Alt+Space into Esc Ctrl+Space when a Gnome-terminal window is active. This is not easy to do without disrupting other applications in most environments.

In short, if you want to use this binding, you'll need to use a different terminal emulator, such as xterm (where escape sequences for key combinations are fully configurable).

Community
  • 1
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • Interesting. Easiest solution is changing terminal or sequence, but not favorite. BTW, i wonder why someone downvoted this answer. – Link-akro Mar 22 '15 at 19:16
  • Using Ctrl+V (quoted-insert macro) is not what I need to study sequences. It only inserts the byte. Inserting a byte is not a clue to know what code it is. It is not easy to read something like "it tried to insert NUL". **SO i will use `hexdump` program from now on to see the exact code of any sequence.** – Link-akro Mar 26 '15 at 18:42
  • @Link-akro You need Ctrl+V with some sequences to prevent the terminal or the application in the terminal from interpreting the initial control character. Then you can type the sequence in `hexdump` if you want to see the hexadecimal codes. – Gilles 'SO- stop being evil' Mar 26 '15 at 22:50
1

Your gnome-terminal (actually the underlying vte-0.34) emits the wrong sequence for ctrl+Alt+space. The bug (https://bugzilla.gnome.org/show_bug.cgi?id=710349) was fixed in vte-0.36.

If you're not afraid of hacking a little bit and you're able to safely revert things in case of trouble, you can try to install vte-0.36 on your Ubuntu 14.04. You'll get many other fixes and improments along with this one. You might find a PPA or a package in Gnome3 staging, or compile it for yourself. Upgrading to this version of vte doesn't require touching any other software components. A complete restart of gnome-terminal is required (close all the windows).

egmont
  • 5,555
  • 1
  • 21
  • 28
  • Thank you for **linking this bugreport**, i could never find it, and it is **stronger than a workaround**. However finding package and version is a pain : my package manager (apt) do not find vte or libvte, and i found a version 2.90 in my computer. _I need to figure out how to upgrade and what upgrade before accepting the answer._ – Link-akro May 08 '15 at 04:17
  • 1
    @Link-akro There's a vte3_1:0.36.3 package at Gnome3 staging (https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging/+packages), I believe installing this should work. It's actually multiple packages, upgrade whichever ones you already have installed; probably `libvte-2.90-9` and `libvte-2.90-9-common`. Should anything go wrong, open an xterm and perform an `apt-get install --reinstall libvte-2.90-9 libvte-2.90-9-common` to revert. – egmont May 08 '15 at 09:15
  • I learnt right now searching with apt (because I was wrong before). I now see the packages already installed : `apt search vte` reports `libvte-2.90-9/trusty,now 1:0.34.9-1ubuntu1 amd64 [installed]` and `libvte-2.90-common/trusty,now 1:0.34.9-1ubuntu1 all [installed]`. (I still do not understand the meaning of every data). **Anyway, local package is up to date** from what i see and `apt-get install libvte-2.90-9` or with `--reininstall`. **And I still have the key sequence bug in gnome-terminal.** Maybe something need compile, IDK. – Link-akro May 08 '15 at 15:40
  • Woops, i forgot your suggestion of 0.36.3 version. It is normal to still have the bug with the 0.34.x. Let me see gnome3 repository for 0.36 correction. – Link-akro May 08 '15 at 15:51