Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

bash refuses to give me the output of 'bind -p' when I pass it in with the -c switch:

bash -c 'bind -p'

but it works to type

bind -p

directly at the bash prompt, and it works to type something like

bash -c 'echo "hi"'

and zsh happily does exactly what bash refuses to do (well, the equivalent command in zsh):

zsh -c 'bindkey -L'

What on earth is going on???

share|improve this question
(If you're wondering why I need to pass 'bind -p' to bash rather than just typing it at the command line, it's because I'm using a system call from a Ruby program.) – iconoclast Nov 3 '10 at 4:21
bash -c 'bind -p' works for me. – Dennis Williamson Nov 3 '10 at 4:58
up vote 3 down vote accepted

When you run bash with the -c option, bash runs in non-interactive mode. Apparently, the bind builtin doesn't generate output when bash is in non-interactive mode. You can force bash to interactive mode by giving the -i option. The following works for me:

bash -i -c 'bind -p'
share|improve this answer
ok, for bonus points, can you explain why you and I are having it work this way, but Dennis Williamson is not? – iconoclast Nov 5 '10 at 23:28
@Brandon: I would need to know more about his shell environment to even begin to hazard a guess. – Steven Monday Nov 5 '10 at 23:56
@Brandon: Probably a version issue. bind -c 'bind -p' gives no output for me with Bash 3.2.39, but produces the same output as with -i or set -o emacs with Bash 4.1.15. Without -i or set -o, Bash 4 additionally emits bash: line 0: bind: warning: line editing not enabled on stderr. – Gilles Nov 13 '10 at 15:20

OK, I have a partial answer that I just discovered after entering my question...

If I type

bash -c "set -o emacs && bind -p"

then it gives the output of the bind command. It seems that for some reason bash doesn't have a default key map, which is really odd.

(I had had something sourced by my .bash_profile which had an error--something that worked fine in zsh but which bash choked on (apparently bash doesn't allow using 'else' in scripts!?)--and so I just disabled it, figuring default settings would be cleaner anyway.)

It's almost unthinkable that bash doesn't default to either a vi or an emacs keymap. Or is there something else going on that is escaping me?

share|improve this answer
Bash does allow else in scripts. – Dennis Williamson Nov 3 '10 at 4:59
OOOOOOPS! I mis-read that as "Bash doesn't allow else in scripts", hence my (previous) comment that that is weird. – iconoclast Nov 9 '10 at 17:49
set -o emacs has the disadvantage of possibly conflicting with set editing-mode vi in the user's ~/.inputrc. – Gilles Nov 13 '10 at 15:21
@Gilles: would the conflict cause the set -o emacs to fail? – iconoclast Nov 18 '10 at 3:45
No, but it means that the resulting information will not describe an interactive instance of bash started without --norc. Depending on what you're using the information for, this may be a good or a bad thing. – Gilles Nov 18 '10 at 8:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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