A kind of FAQ for bash on Debian GNU/{Linux,Hurd}
-------------------------------------------------

0. symlinked directory completion behavior

   Starting with readline-4.2a, completion on symlinks that point
   to directories does not append the slash. To restore the behaviour
   found in readline-4.2, add to /etc/inputrc or ~/.inputrc:

       set mark-symlinked-directories on

1. How can I make /bin/sh point to something else?

   Type

	dpkg-divert --add /bin/sh

   and then point it to whatever you want. Upgrades to bash  won't upgrade
   the /bin/sh symlink. To put /bin/sh under dpkg control again, type

	dpkg-divert --remove /bin/sh


2. How can I make bash 8-bit clean so I can type hi-bit characters
   directly?

   Remove the comments from the indicated lines in /etc/inputrc.
   It doesn't ship this way because otherwise the Meta bindings will not work.

3. How to get rid off annoying beeps for ambiguous completions?

   Put in /etc/inputrc (or in your ~/.inputrc):

	set show-all-if-ambiguous on

   Other people prefer:

	set bell-style none

4. bash doesn't display prompts correctly.

   When using colors in prompts (or escape characters), then make sure
   those characters are surrounded by \[ and \]. For more information
   look at the man page bash(1) and search for PROMPTING.

5. What is /etc/bash.bashrc? It doesn't seem to be documented.

   The Debian version of bash is compiled with a special option
   (-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc
   for interactive non-login shells. So, on Debian systems,
   /etc/bash.bashrc is to ~/.bashrc as /etc/profile is to
   ~/.bash_profile.

6. bash does not check $PATH if hash fails

   bash hashes the location of recently executed commands. When a command
   is moved to a new location in the PATH, the command is still in the PATH
   but the hash table still records the old location.

   For performance reasons bash does not remove the command from the hash
   and relook it up in PATH.

   Use 'hash -r' manually or set a bash option: 'shopt -s checkhash'.

7. bash unexports SSH_CLIENT in some cases

   Bash uses the presence of SSH_CLIENT to decide whether or not to run
   the shell startup files for a non-interactive shell (like it attempts
   to do for rsh).  The problem is that if the variable is exported,
   subsequent invocations of non-interactive shells will source the
   startup files.  A lot of users find the former behavior desirable, and
   the latter undesirable.  The tradeoff bash makes is to remove the
   export attribute from SSH_CLIENT if it exists in the shell's initial
   environment.  Users may always export it explicitly.

   Further information can be found at

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=88032&repeatmerged=yes

8. Bourne-style shells have always accepted multiple directory name arguments 
   to cd.  If the user doesn't like it, have him define a shell function: 
 
   cd() 
   { 
        case $# in 
        0|1)    ;; 
        *)      echo "cd: too many arguments ; return 2 ;; 
        esac 
        builtin cd "$@" 
   } 

9. key bindings for ESC

   Consider the following .inputrc:

   set editing-mode vi

   keymap vi
       "\M-[D":        backward-char
       "\M-[C":        forward-char
       "\M-[A":        previous-history
       "\M-[B":        next-history

   And, just to be certain, set -o reports that vi is on.

   However, ESC k does not send me to the previous line.

   I'm guessing that this is a conflict between bash's concept of a meta
   keymap and its concept of vi's command-mode character -- which is to
   say that its data structures don't properly reflect its implementation.

   Note that if I remove the meta prefix, leaving lines like:
       "[A":        previous-history

   That vi command mode keys work fine, and I can use the arrow keys in vi
   mode, *provided I'm already in command mode already*.  In other words,
   bash is doing something wrong here such that it doesn't see the escape
   character at the begining of the key sequence even when in vi insert mode.

   Comment from the upstream author: "This guy destroyed the key binding for
   ESC, which effectively disabled vi command mode.  It's not as simple as he
   paints it to be -- the binding for ESC in the vi insertion keymap *must*
   be a function because of the other things needed when switching
   from insert mode to command mode.

   If he wants to change something in vi's command mode, he needs
   to use `set keymap vi-command' and enter key bindings without
   the \M- prefix (as he discovered)."

10. Why is bash configured with --disable-net-redirections?

    It can produce completely unexpected results. This kind of
    feature should not be part of a shell but a special. tool. And
    that tool has existed for years already, it's called netcat.