Remote SSH Commands - bash bind warning: line editing not enabled
ssh host 'ls -als'
When you ask ssh to run a command on the remote system, ssh doesn't normally allocate a PTY (pseudo-TTY) for the remote session. You can run ssh with
-t to force it to allocate a tty:
ssh -t host 'ls -als'
If you don't want to type that all the time, you could add this line to the ".ssh/config" file on your local host:
Alternately, you could fix the ".bashrc" file on your remote system to avoid running commands that presume the session is interactive when it isn't. One way is to enclose the commands in a test that the session has a TTY:
if [ -t 1 ] then # standard output is a tty # do interactive initialization fi
Having an interactive session is not enough for
bind to work. For instance emacs shell provides an interactive session which passes the
if [ -t 1 ] test but it does not have the line editing so any
binds in your
~/.bashrc will generate the warnings. Instead, you can check if the line editing is enabled by doing something like this (is there a simpler/better way?):
if [[ "$(set -o | grep 'emacs\|\bvi\b' | cut -f2 | tr '\n' ':')" != 'off:off:' ]]; then echo "line editing is on" fi
If there is no line editing, these
bind commands themselves are harmless. Suppress the warnings:
bind '"^[[A":history-search-backward' 2>/dev/null bind '"^[[B":history-search-forward' 2>/dev/null
This is somewhat inelegant, still it should work. Other answers don't agree about the best/sufficient test. My approach circumvents this. It doesn't scale well though. The two commands alone should not make a big difference; but if you had more, like dozens, then a proper conditional would probably be better.