in reply to Re: (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.
in thread (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.

I've followed these instructions to the letter, and still nothing works.

Whether I use a vanilla putty session, (I blew it away and re-installed from scratch to ensure that nothing was left over from my earlier attempts to configure). Or a vanilla SSH 3.2.9 (build 283) (Also re-installed from scratch).

In both cases, with the .inputrc file from above, uploaded using the SSH file transfer widget and bound using the command shown. Nothing works.

I also tried logging out and logging back in, in the forelorn hope that the .inputrc file would be read and acted upon when a new session was started, but still nothing changed. I think that the problem lies in the set up at the host end rather than PC end. Maybe it is non-standard. Surely not everyone using a (RH 7) linux system has to go through this?

None of the edit keys do anything at all except the backspace key? I cannot even retrieve the previous command using the up-arrow.

All of which has made my use of Linux over the last 6-weeks a less than wow experience.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
  • Comment on Re: Re: (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.

Replies are listed 'Best First'.
Re: Re: Re: (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.
by flyingmoose (Priest) on Mar 03, 2004 at 13:32 UTC
    Maybe your SSH client is junk. What happens when you SSH from a similar linux system to another? PuTTY works well for when I need to use a Windows client (which is not often -- but PuTTY is decent).

    Also, which Linux distribution (name and version) is this?

      Thanks, but I have tried no less that 7 different shells: Putty, SSH 3.2.9, Secure Koala Term, Tera Term, AniTa and a couple of others that I failed to keep track off.

      All have some advantages and disadvantages.

      • Putty

        I can't find a way to resume the current session when my isp drops the ball.

      • SSH 3.2.9

        This better in some senses in that it remembers what host and userid you were using and only requires you to hit the spacebar and retype the password, but it has other constraints. It only seems to do one sort of terminal emulation, and that emulation doesn't have any way of distinguishing between cursor-left and control-cursor-left etc.

      • AniTa

        Very powerful. Emulates almost anything you could want, has fully configurable keyboard mappings, scripting language and a lot more besides. Unfortunately, it also comes with a load of 3d-whizzy baggage that gets in the way, and spreads it's configuration across about a dozen files and dialogs in a way that is almost incomprehensible. I simply gave up trying to work out how to set it up.

      • Secure Koala Term is pretty neat. Unfortunately it tries so hard to emulate a limited set of Dec terminals that were old hat when I started programmng and haven't been manufactured since before many of the people reading this were born, that it is severly limiting. If your an afficinado of Dec's EDT editor it would be great, but the last time I used that was 1984.
      • Tera Term

        I forgot why I threw this one out. Needless to say, I wasn't too impressed.

      The main problem I was having was more to do with finding out what functions where available (bind -p), and what they did, which isn't entirely obvious from their names.

      Then what character sequences were generated by what keys, and that depends on which terminal your emulator emulates.

      Finally, somewhere in one of my attempts to configure the keyboard to what I consider to be a rational set of mappings, I obviously deleted something vital because I arrived at a point where simply nothing worked.

      My hope was that someone with a good understand of the interactions between emulator types/ vi -v- emacs modes, bind, .inputrc, readline and all the other bits and pieces that go together to cause pressing a key on my keyboard to do something on the host had already done the work.

      The BOFH that manages the system in question has managed to restore the status quo and enhance it somewhat closer to my idea of a sensible configuration. The mappings only seem to work with Putty -- not SSH or any of the others for reasons that completely elude me, but it's better than where I was a few days ago:)


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
        I can't find a way to resume the current session when my isp drops the ball.
        This is not Putty's problem -- it's your ISP's. Linux SSH won't auto resume either, nor should it... you are essentially logging out once that connection dies.

        PuTTY is a great app since it comes from the OpenSSH folks. If you really want it to work better, I'd try SSH from Linux when your terminal/input probably won't suck so badly -- but I have never heard anyone complain about PuTTY. Admittedly, SSH on Windows is slower than on Linux (esp with SFTP), but that's not too bad.