2

I have read that pressing Ctrl+G in the terminal produces a beep sound. I have tried it and nothing happens. Why?

I am using GNOME Terminal and Bash.

apaderno
  • 825
Joseph
  • 375
  • That statement probably refers to a certain situation. The simple answer is probably that your system is not configured that way (and it is not the default). Is your question how you can configure this behaviour? – Hauke Laging Oct 29 '17 at 07:45
  • @Hauke Laging I didn't know that this behavior can be enabled/disabled, in that case, how can I enable it? – Joseph Oct 29 '17 at 07:47

1 Answers1

14

Pressing Ctrl+G on your keyboard has your terminal emulator send the 0x7 byte, aka ^G which in ASCII is the BEL character aka \a (alert).

Most terminals issue a beep (or visual bell, like a flashing of the screen), when they receive that character, that is when the application writes that character to the terminal device file, or when the echo of the tty discipline of that terminal device sends it back unmodified.

If you enter:

printf '\a'

Or:

printf '\7'

You should see a flash or hear a beep.

If not, check your terminal emulator configuration, bells may be disabled by default. You may also need to enable it globally in your desktop environment for fancy integrated terminal emulators like gnome-terminal. If that still doesn't work try with a proper terminal emulator like xterm.

In X11, terminal emulators (or the libraries they use) will typically call the XBell() standard X library function to cause a beep when they've not been configured to do screen flashing.

That beep (pitch, base volume, duration) can be configured with the xset b command.

On Linux and on PCs, by default, the X server will use the PC Speaker. However nowadays, the pcspkr is usually disabled by default.

Instead, applications can register with the X server to handle those bells. The pulseaudio sound server used in many desktop environments can do that.

If it's not already configured to do it, you can uncomment or add these lines to your ~/.config/pulse/default.pa file (or /etc/pulse/default.pa for system-wide):

load-sample-lazy x11-bell /usr/share/sounds/freedesktop/stereo/bell.oga
load-module module-x11-bell sample=x11-bell

(replace the sound sample with one of your choice).

Now, to hear a beep when you press Ctrl-G, you'd need the application to echo that ^G character. Or for applications that don't have their own line editor, have the tty device line discipline echo it when in icanon mode.

By default, the line discipline on Linux will echo it, but it will echo it as ^G (^ and G characters). That can be changed with

stty -echoctl

If you do:

stty -echoctl; cat

You'll hear the beep or see the screen flashing upon Ctrl+G. While without the stty -echoctl or after stty echoctl, you'd see ^G being displayed upon Ctrl+G.

At the prompt of an interactive shell application like zsh or bash, or within a visual application like vi, emacs, mutt, aptitude... the application may decide to do whatever it wants upon reading that BEL/^G character from the terminal device file.

In emacs ^G is for aborting the current editor action. It's the same in zsh or bash when in emacs mode (with bash or other applications using GNU readline, that's also affected by the bell-style and prefer-visible-bell parameters). As part of that, they do send a ^G character back to the terminal, which should cause a beep/flash.

Some possibly relevant commands to query the current configuration (many of which only apply to GNU/Linux systems using a gtk-based desktop environment and pulseaudio):

  • Check the terminal device line discipline echo-related parameters (for applications like cat that don't implement their own terminal user interface (TUI)):

    stty -a | grep echo
    
  • What action is mapped to ^G at the prompt of your shell:

    bindkey '^G' # in zsh or tcsh
    bind -p | grep C-g # in bash
    
  • bell related settings in the GNU readline configuration:

    grep bell /etc/inputrc ~/.inputrc
    bind -v | grep bell # bash
    
  • bell related settings in the xterm terminal emulator:

    appres XTerm | grep -i bell
    
  • in some gtk-based terminal emulators or environments:

    gsettings list-recursively | grep -i bell
    dconf dump / | awk '/^\[/{p=$0};/bell/{print p ORS $0}'
    gconftool -R /apps/gnome-terminal/profiles | grep bell
    
  • X11 bell configuration:

    xset q | grep bell
    
  • bell-related configuration in pulseaudio:

    pactl list | awk -vRS= -vORS='\n\n' '/bell|pcsp/'
    

    (on a Linux Mint Cinnamon system here, /usr/bin/start-pulseaudio-x11 does a /usr/bin/pactl load-module module-x11-bell "display=$DISPLAY" "sample=bell.ogg" but never defines/uploads the bell.ogg sample, so the bell doesn't work until you do pactl upload-sample /usr/share/cinnamon/sounds/bell.ogg bell.ogg for instance)

  • whether the pcspkr or snd-pcsp kernel module is loaded:

    lsmod | grep pcsp
    
  • whether they are explicitly disabled (blacklisted):

    grep -r pcsp /etc/modprobe*
    
  • loaded but disabled?

    find /sys/module -path '*pcsp*/enable' -exec grep -H . {} +
    
  • whether the PC speaker is available as an ALSA device:

    alsactl -f alsa.dump store; sed '/pcsp/,/^}/!d'  alsa.dump
    
  • does ^G sent to the Linux virtual console emit a beep?

    printf \\a | sudo tee /dev/tty0
    
  • Does playing the x11-bell (assuming one is defined) emit a sound?

    pactl play-sample x11-bell
    
  • is there an input event device registered by the pcspkr module?

    find /sys/class/input -lname '*/pcsp*/event*' -ls