Astro inputrc/esc-k doesn't work

[wysiwyg]

When my account was setup on Astro the edit-mode (set -o vi) did not work at all. I emailed support and received a reply suggesting I read the man pages and that it worked just fine for him.

Looking at the server settings my own dang self since the support tech wouldn't do it I discovered the following:

1. The environmental variable INPUTRC is set to /etc/inputrc so the home directory copy is not read.

2. vi-movement-mode is not bound to any key. Therefore: no vi movement mode.

My solution was as follows:

Add the following two lines to .bash_profile

INPUTRC=~/.inputrc
export INPUTRC

I changed my .inputrc to the following

$include /etc/inputrc
"\C-[": vi-movement-mode

Changing the first line to
. /etc/inputrc
is not recommended as very bad things would occur. :-)
[This message has been edited by wysiwyg (edited 04-16-00@11:02 pm)]

[Terra]

Setting up your Linux/Unix environment is beyond the scope of technical support considering the myriad of options/choices available for a custom configuration...

The '/etc/inputrc' is a RedHat Linux default which has thus been changed in light of your 2 emails to 'support@'...

I will be making sweeping changes to all servers to deviate from the general Redhat default...

We cannot guess the best setup for any particular individual which is why we go with the most basic of '.inputrc' settings...[nbsp][nbsp]Also consider that site owners have a choice between Bash/csh/ksh/ash/etc for their system shell...

However, we do leave the ReadLine libraries open for full customization with no restraints, for which you have discovered how to override (now ~/.inputrc on by default) and custom configure your own...

I am glad to see that you found the sequence you required and I will look closer at '"\C-[": vi-movement-mode' as a core system default on startup/login...

--
Terra
--Perfection == being everything to everybody--
FutureQuest

[wysiwyg]

Is inputrc used by shells other than bash?

As far as this goes:

"Setting up your Linux/Unix environment is beyond the scope of technical support considering the myriad of options/choices available for a custom configuration..."

This is a TERRIBLE response to a statement that 'set -o vi' didn't work. You're saying that support for use of the unix shell is somehow unreasonable? That the original reply that I should read the manuals and figure it out myself was appropriate? In 8 years I haven't used a unix bash/ksh that didn't have this binding.

I don't usually get bent out of shape on something like this but getting an RTFM response to a request for assistance in figuring out why 'set -o vi' didn't work was really obnoxious.
[This message has been edited by wysiwyg (edited 04-16-00@11:42 pm)]

[Deb]

As Andrew stated above this is being rectified in light of your messages which should solve the problem you were having.[nbsp][nbsp]If at any time you receive a response that you feel wasn't appropriate or didn't solve the issue then by all means let us know and we'll see if we can work together to solve the issue at hand.[nbsp][nbsp]

The email Andrew originally sent you was detailed and complete with the information he had in front of him at the time.[nbsp][nbsp]Further digging would reveal that another solution is available and now that is being addressed.

Deb
[nbsp]- Choose Your Destinations
[nbsp][nbsp] Business to Client = Three links to the left.
[nbsp][nbsp] Client to Business = Three links to the right.
[nbsp][nbsp] Team Work and Effort = Here and Now.

[Dan Kaplan]

If I may interrupt, you're not going to make many friends around here bashing the tech support which we all love dearly.[nbsp][nbsp]I don't know the specifics of your situation, but I can guarantee you FQ support is as professional and helpful as they come.

Dear

[wysiwyg]

--
If I may interrupt, you're not going to make many friends around here bashing the tech support which we all love dearly.[nbsp][nbsp]I don't know the specifics of your situation, but I can guarantee you FQ support is as professional and helpful as they come.
---

If a tech doesn't know the answer, then fine, I would hope that he would ask someone else. Receiving a reply telling me to read the man pages, finding that the server I'm on isn't configured 'normally', and then being told that shell support "beyond the scope" of technical support annoyed me just a bit.

And if you don't like that I said so you, sir, can go hang.
[This message has been edited by wysiwyg (edited 04-17-00@12:29 pm)]

[Terra]

A misinterpretation...[nbsp][nbsp]Bash uses ReadLine, whereas the others have internal binding operators e.g. csh...

I mentioned the other shells is the reason why we must go with the most stripped down basic of environments to start you off with...[nbsp][nbsp]Customizing your environment is in fact contained within the Bash documentation (man pages)...

figuring out why 'set -o vi' didn't work was really obnoxious. Even the sentence above with 'set -o vi' ends with a period, but from a technical standpoint 'set -o vi' was in fact working...

A paste from your original email: [FQ034707] edit buffer (set -o vi)

For some reason I can't get use 'set -o vi' to enter VI mode from the shell
prompt. I'm using bash, $EDITOR is set to vi but 'esc-k' doesn't put the
previous line from my history file into the input field.

The part of this equation that was not working was the 'esc-k' for which is a customization will/would solve...

That alone may have been enough to throw me off the original trail and take a 'right' when I should have followed the 'left' path for isolation...

Also, testing the 'esc-k' was done while I was logged in on ASTRO was working for me...[nbsp][nbsp]My 'profile' has been customized over time and bash2 was picking up on my local .inputrc file...[nbsp][nbsp]Curious though that it worked for me even though I did not have to make the '\C-[": vi-movement-mode' change...

Once again, thrown off the trail, I deduced that you must have had a local configuration problem unique to your environment as it appears you have been perfoming customizaton work with it...

One more note: I cannot assume that everyone will use the 'vi' binding keys as there are many 'emacs' fans out there that use this readline mode as well...[nbsp][nbsp]In situations such as this, with multiple choice answers, it's always best to not assume what a particular individual will or won't utilize...

Hence we setup minimal environments and allow the site owners, which possess Unix/Linux experience, to put that knowledge to work for themselves and allow them to customize unrestricted...

In conclusion, you have in fact identified a broken RedHat assumption (that I could have sworn I fixed long ago) with the /etc/inputrc overriding your local '.inputrc' one...[nbsp][nbsp]I am assuming that recent server upgrades tweaked the system profile and injected these lines back in...

On the flipside, I tested your report 'as-is' and it worked for me, else I would have deduced that something was amiss somewhere within all of the activities that happen during login environment creation...

--
Terra
--if ... elsif ... elsif ... elsif ... elsif ... elsif ... else--

[jimbo]

Just my .02, but what part of:


The '/etc/inputrc' is a RedHat Linux default which has thus been changed in light of your 2 emails to 'support@'...

I will be making sweeping changes to all servers to deviate from the general Redhat default...

Do you find to be a "terrible" response?[nbsp][nbsp]Try to find another host that would be as responsive.

==

Andrew-[nbsp][nbsp]I'd like to thank you for making these changes.

[wysiwyg]

Do you find to be a "terrible" response?[nbsp][nbsp]Try to find another host that would be as responsive.

What I actually said was that the response that shell support is "beyond the scope" of support was a terrible response to the problem I reported (two weeks ago). I found the solution for myself today and posted it here in case anyone else ran into it. Also, the man pages, which I was told to read, states that the default is ~/.inputrc which is why I noticed that the current setting was actually /etc/inputrc. Plus this is only part of the problem, the oher being that the vi-movement-mode wasn't bound; which is a first for me.

While I appreciate the difficulties of tech support literally being told to read the man pages, and given what the actual solution turned out to be, caused me to be rather unhappy with the original response.


[This message has been edited by wysiwyg (edited 04-17-00@12:53 pm)]

[wysiwyg]

Terra,

I apologize for getting bent out of shape on this one; I know you work hard, and on weekends.

[Terra]

Nah, no apologies needed...

I for one know exactly how *#$frustrating@%* Linux/Unix can be at times, especially when you head down the wrong path while testing/isolating a particular scenario/situation...

Reminds me of a favorite saying in the *nix world:
It isn't that unix isn't a user friendly operating system, it's just choosy about which users it wants to be friends with, and even the best of friends occasionally fight.

--
Terra
--Water under the bridge--
FutureQuest