Can't backspace in Nano

Is anyone else having problems doing a simple backspace in Nano? When I hit the Backspace key, Nano does a forward delete instead of a backward delete. (The Delete key does a forward delete as expected.)

Strangely, backspace in Pico works fine, while the Delete key gives an "Unknown Command" error.

Anybody know how to fix this problem? I've tried messing around with .inputrc and .nanorc, but nothing seems to work.

In reply to:

---

Is anyone else having problems doing a simple backspace in Nano?

---

No. Backspace works as expected here in Nano, running it in PuTTY on WinXP.

Mark

No problems here.

Edited by nuwake on 04/17/06 02:50 PM (server time).

Try removing your .nanorc and .inputrc files.
There is only a /root/.inputrc which contains:-

# $Id: dot-inputrc,v 1.2 2002/02/22 02:52:56 william Exp $

# Will Yardley - william@hq.newdream.net

"C-w": backward-kill-word

# Brian

"e[5C": forward-word
"e[5D": backward-word


Check that Nano then works as it should and then rebuild your .nanorc with reference to :-
/usr/share/doc/nano/examples/nanorc.sample.gz

(gunzip it for the nanorc.sample file)

Ensuring that any characters interpreted by the shell are

Try removing your .nanorc and .inputrc files.

Thanks for the suggestion, but unfortunately it didn't help.

I should probably point out that I'm using the Mac OS X (10.4) terminal. However, I have three other Linux boxes at work, all with different distributions, and I have no problem with backspacing in nano while logged in to them. Only on the DreamHost server is backspace interpreted as forward-delete in nano. (However, as I said, pico and bash itself don't have this problem.)

There is only a /root/.inputrc which contains:-

There's an entry in that file that looks like this:

"e[5D": backward-word

This indicates that Control-Left is mapped to backward-word, and I can confirm this in bash by typing Control-V then Control-Left. I get:

^[[5D

However, if I type Control-Left directly, I see only this:

D

Does that mean anything?

Maybe you have a setting elsewhere that is effecting what you do in nano.
What shell are you running in your Mac. I do not have a Mac under OS X but do you have a .tcshrc or .cshrc in your home folder/directory (or even .bashrc !). Terminal will pick up options from there so try using the entry:-

bindkey -v

in that file and see if that works after a user re-login or 'source .tcshrc'.


Just spotted that you said bash so you may have a .bashrc in that case or a .bash_profile which you can try.


--
NormEdited by norm1037 on 04/18/06 03:15 AM (server time).

Thanks for the suggestions. I did some more investigating, and here's what I found out:

1. If I go to a Linux box and log into DreamHost from there, the problem goes away. So that means there's definitely something about my Mac OS X workstation that's causing this problem.

2. I'm running bash, but there are no bash settings in my user account causing this problem. I've confirmed this by logging into a newly-created user account on my Mac OS X box and then logging in to my DreamHost account, which still gives me the same problem. I also deleted my .bashrc and .bash_profile, created a new terminal window, logged on to DreamHost, and still had the same problem.

3. I tried doing the "bindkey -v" command, but it appears that this is not recognized in bash. From my bash shell, I ran tcsh, which got me a tcsh shell, and that recognizes bindkey, but it gives no output. I tried logging on to DreamHost then, and that still gives me the same problem. I think that rules out bash as the source of the problem, but I'm not entirely sure.

Any other suggestions are welcome. Thanks!

I cannot think of much more now. It may be a case of doing the rounds of the Mac forums.

Have you looked through all the rc files in the /etc folder, the ones without the dots?

What about a keybd file like the US and GB keybd layouts that need changing under Linux to get the £ and the ~ in the right place?

Or, removing the / escape characters in the current inputrc and nanorc files you are trying out?

/root/.inputrc has nothing to do with any of this. /etc/inputrc does. But this is much more likely to be a problem with the terminfo definition your terminal client is declaring. Terminal.app claims to be xterm, but has some slight differences.

What does "stty -a" say? (look to see what it says after "erase")
What does "echo $TERM" say?
does "export TERM=nsterm-16color" fix anything?
(this is theoretically the "right" terminfo def for recent Terminal.app versions, though to be honest, I still have better luck with xterm or xterm-color).

Does doing:
$ stty erase ^V[backspace]
(that's control-v and then backspace)
fix it?

Bash and some programs (maybe including pico) do some extra smartness so that things work whether backspace sends ^H or ^?

I've had some vaguely similar problems in the past (mostly with some homebrew stuff using Term::Readline).

What does "echo $TERM" say?
does "export TERM=nsterm-16color" fix anything?
(this is theoretically the "right" terminfo def for recent Terminal.app versions, though to be honest, I still have better luck with xterm or xterm-color).

Ah-ha! That was it! Terminal was set for xterm-color, and for some reason nano on DreamHost prefers plain old xterm. A simple "export TERM=xterm" fixed everything. Thanks for the tip!

Please see my reply to Will. Turns out nano on DreamHost doesn't like the xterm-color terminal type for some reason.

Thanks for all your suggestions!