Say I have a process running in a terminal in the foreground. While it is active I can type commands, hit return, and those will be executed once the process is done.

Now say furthermore I would like to input control characters instead of just "normal" letters. For some reason those control characters are echoed literally but not interpreted properly once the foreground process finishes.

Allow me to illustrate this problem with an example:

deso@XXX ~ $ sleep 10
echo test
deso@XXX ~ $ echo test

While sleep is active I type 'echo test' (followed by return) and it gets executed after 10 seconds. Now in the same terminal I do (this is the literal output I see):

deso@XXX ~ $ sleep 10
deso@XXX ~ $ echo

deso@XXX ~ $

My intention here is to invoke the readline's reverse history search feature while sleep is active (this should find the 'echo test' I entered before). If the shell is waiting for my input Ctrl-R accomplishes this feat. With an active process the Ctrl-R is seemingly ignored (at least it does not start the reverse history search). This is all on Linux (with xterm + tmux + bash; but I tried without tmux and with busybox instead of bash).

Now what is interesting is that on VMware ESX (which uses busybox, i.e., ash, as the shell) things work as expected, that is, the control character is not echoed literally but rather accepted as a control character and interpreted (along with the remaining characters) once the foreground process is done. That means in the example above the history search would have been invoked, the last 'echo' command ('echo test') would be found and it would be executed.

My question is: who influences this behavior? The terminal, the shell, the kernel? Is there a way to get Linux to behave like ESX in that respect? As I mentioned I have tried the same experiment with different shells (bash & ash) and different terminal emulators (xterm & urxvt). The behavior is always the same.

  • The behavior you describe in ESX is unexpected. If you type stty -a on your ESX system, does it show rprnt=^R ? – Mark Plotnick May 8 '17 at 3:13
  • Can you elaborate why said behavior is unexpected? The stty -a output on ESX does not contain rprnt at all. My local setup has rprnt=^R. – deso May 9 '17 at 5:22
  • It's unexpected because on most Unix systems derived from BSD, and Linux, control-R reprints the current input line. This is useful when some background process produces output while you're typing. Commands like bash which use readline override that, and use control-R to do reverse search if you're using emacs-style bindings, but they're careful to restore the default before they run another foreground command. I thought ESX (as opposed to ESXi) was Linux-based. – Mark Plotnick May 9 '17 at 10:28
  • 1
    Try stty rprnt undef on your Linux system. That ought to be sufficient to leave control-R in the input buffer when you type ahead of the shell resuming after it has run a foreground command. – Mark Plotnick May 9 '17 at 10:35
  • 1
    Thanks Mark! When I said ESX I meant ESXi. Sorry for the confusion. Indeed stty rprnt undef did the trick! It's not exactly the same behavior (the ^R is still echoed [not a problem]) and I have to press return twice but that is a small price to pay. – deso May 12 '17 at 1:48

Your Answer

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

Browse other questions tagged or ask your own question.