Re: Unable to Use Backslash Under Remote Bash shell
From: Greg Wooledge (wooledg_at_eeg.ccf.org)
Date: Tue, 5 Aug 2003 10:50:54 -0400 To: Jeff Hill <email@example.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).