Re: Unable to Use Backslash Under Remote Bash shell

From: Greg Wooledge (wooledg_at_eeg.ccf.org)
Date: 08/05/03

  • Next message: Jeff Hill: "Re: Unable to Use Backslash Under Remote Bash shell" 
    Date: Tue, 5 Aug 2003 10:50:54 -0400
To: Jeff Hill <jhill@hrpost.com>

    On Tue, Aug 05, 2003 at 10:16:08AM -0400, Jeff Hill wrote:
    > I tried your suggestiong about a bad dot file, but couldn't find anything
    > strange. I tried removing everything from my .bashrc and .bash_profile
    > files except a basic path statement; no luck there.

    Yeah, if it wasn't stty, then I can't think what it could have been
    inside of a dotfile, unless someone went out of his way to make the
    dotfile act badly. (stty could easily be screwed up by accident.)

    The second thing that came to mind for me was that you might have
    something very wicked happening in your terminfo/termcap setup.
    Check your $TERM variable, and also the output of "infocmp". (But
    if you're not already familiar with terminfo, then it could be a
    bit overwhelming.) Anyway, if you have some key's escape sequence
    mapped to "\", then perhaps the remote copy of bash is interpreting
    "\" as "F2" or whatever, therefore doing nothing.

    (Hint: "\E" in infocmp's output is "Esc", and the fields that begin
    with "k" (e.g. kdch1) are escape sequences for keys. Debian doesn't
    use termcap at all, so we don't need to worry about that one, I hope.)

    To rule out any client-side remapping issues, you can press "Ctrl-V"
    and then "\" to see the literal bytes being sent by your backslash
    key. If you just see "\" on the screen, then you know the client side
    is sending it through unmolested.

    I'm inclined to think that this issue is not ssh-specific, but I must
    admit I don't know exactly what's causing it, so I can't rule anything
    out at this point (except stty, which we already checked).

  • Next message: Jeff Hill: "Re: Unable to Use Backslash Under Remote Bash shell"