Terminal randomly stops working after I run a command. The input prompt is shown but it will not take any input any more. I tried running ls, but nothing happens.

After I click Terminal > Reset and clear, the screen goes black and the input prompt is not shown at all, just the white cursor, still not accepting any input. See this screenshot:

enter image description here

I can open another tab which works fine.


Happened again after I ran a git add command in a different folder as the one before. I then typed a git commit -m "message" command and the shell wouldn't react on my pressing enter. Again I opened another tab with Ctrl+Shift+T and copied my git commit command and it worked. Typing reset and Enter in the frozen tab doesn't do anything. So far it seems to be happening randomly.

Bellow is my ~/.bashrc:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion

export PATH=$PATH:~/custom-bash


It could indeed be the Ctrl-S problem. I don't remember pressing this key combination after typing the git commit command however pressing Ctrl-Q all of a sudden ran all my typed commands (the Enters I pressed and the reset command which reset bash on the tab I think - the tab cleared).

I will come back if this problem occurs and I solve it with Ctrl-Q. I'll also know for sure if I pressed Ctrl-S by accident or if some other process blocked the terminal, if that's possible.

  • 2
    Does this happen after any command at all? Only specific ones? Either way, it sounds as though you might have set something bad as PROMPT_COMMAND. Please edit your question and show us the contents of your ~/.bashrc file.
    – terdon
    Oct 13 '17 at 9:22
  • How can you reproduce? Always on ls? Alway in same directory? Anything in dmesg, like IO errors on disc? Any other problem at the same time? Oct 13 '17 at 10:05
  • Does blindly typing "reset" (and pressing Enter) do anything?
    – egmont
    Oct 13 '17 at 16:15

try control Q maybe the command you run has control S

to disable control S all together stick stty -ixon in your startup

to enable it again stty ixon

  • A command run cannot "have" "control S". This is something that can be pressed from the keyboard, but it has no equivalent that an application could output.
    – egmont
    Oct 13 '17 at 16:15
  • 1
    This could indeed be close to the problem. I'll update as soon as I know more. See the last edit.
    – wraithie
    Oct 27 '17 at 11:49
  • Indeed this response could use some rephrasing. I'll mark this as the answer however, as me pressing Ctrl-S accidentally (while trying to save a file in another window or such) is most likely the cause. More info here.
    – wraithie
    Nov 4 '17 at 0:31
  • 1
    Thank you, i should get +1 instead of -1 then for the answer :) Nov 20 '17 at 4:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.