Lowercase 'e' no longer works in Terminals

English Applications
1

For some reason, just shortly ago, the terminals, konsole, etc. will not accept the lowercase letter ‘e’ as input for some reason, not even when pasting, e.g.

a paste of
file:///usr/share/applications/kde4/konsole.desktop

becomes
fil:///usr/shar/applications/kd4/konsol.dsktop

on the command line. Weird.

For everything else I have tried at this point on the computer, the lowercase letter ‘e’ is just fine (this message being an example);

Has some configuration file for terminals (konsole, xterm, Yakuake) or whatever got messed up and I need to correct it?

Star_Gazer

2

Does this happen on root-terminals too? How about tty1-6?

You should check the output of

locale
3

Well, at this point, the problem is not occurring in root mode. I’m not acquainted with the tty1-6 stuff, though I did note that my normal user/group name is in the attributes of /dev/tty7.

I remember several months ago that the tty could be changed via Ctrl-Alt-Shift-F? keys to change ttys in another Linux Distro.

obviously, I can’t do the ‘locale’ command for the standard user since it has an ‘e’ in it, but here is the readout for root terminal:
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=“POSIX”
LC_TIME=“POSIX”
LC_COLLATE=“POSIX”
LC_MONETARY=“POSIX”
LC_MESSAGES=“POSIX”
LC_PAPER=“POSIX”
LC_NAME=“POSIX”
LC_ADDRESS=“POSIX”
LC_TELEPHONE=“POSIX”
LC_MEASUREMENT=“POSIX”
LC_IDENTIFICATION=“POSIX”
LC_ALL=

Thanx,
Star_Gazer

4

Well, I was able the get the locale output for my non-superuser user account (used the TAB key completion, and here it is:

~> /usr/bin/locale
LANG=en_US.UTF-8
LC_CTYPE=“en_US.UTF-8”
LC_NUMERIC=“en_US.UTF-8”
LC_TIME=“en_US.UTF-8”
LC_COLLATE=“en_US.UTF-8”
LC_MONETARY=“en_US.UTF-8”
LC_MESSAGES=“en_US.UTF-8”
LC_PAPER=“en_US.UTF-8”
LC_NAME=“en_US.UTF-8”
LC_ADDRESS=“en_US.UTF-8”
LC_TELEPHONE=“en_US.UTF-8”
LC_MEASUREMENT=“en_US.UTF-8”
LC_IDENTIFICATION=“en_US.UTF-8”
LC_ALL=
~>

5

Hm, seems okay to me - sorry, beats me for now.

You should still try typing in another tty, meaning logging to a parallel session on a command-line (pretty much as you assumed, just hit Ctrl + Alt + F1-6, you’ll be back on your regular session by Ctrl + Alt + F7), as this might be an issue of your desktop environment - by the way, have you tried typing in an alternative environment yet (Fluxbox or the like)? Another user might be interesting too.

6

You could try :
export LC_ALL=C
and type ‘e’. Does it make a difference?
Also does the output of the following command look unhabitual ?
xmodmap -pk | grep 0065

7

as well as a ssh session if you happen to have another computer (?)

8

Yea, the ‘e’ works in the parallel session. Funny thing, when I do a “su -” at the terminal command line to sign in as root, the ‘e’ does not work then either, yet, if the terminal is first started as root, it works, but does not work if I sign in as the standard user from the root terminal command line.

I went into another linux distro and did not have the problem - I get the feeling that something has gotten messed up in one of the directory in “home/…” realms.

as this might be an issue of your desktop environment - by the way, have you tried typing in an alternative environment yet (Fluxbox or the like)? Another user might be interesting too.

I do not understand the part about typing in a alternative environment, but the idea of creating another user has crossed my mind as well.

Thanks,
Star_Gazer

9

I would love to try those… unfortunately, because those commands export LC_ALL=C and xmodmap -pk | grep 0065[/QUOTE] contain the lowercase ‘e’, thus, I am unable to do those commands :frowning:

I’m calling it a night, maybe it will heal it self in morning :stuck_out_tongue:

Thanks,
Star_Gazer

10

Star Gazer wrote:
> I get the feeling that something has gotten messed up in one of the
> directory in “home/…” realms.

i guess if you were to use YaST to create a new user and then
compared /home/[you]/.bashrc to /home/[new user]/.bashrc you might
find a difference…speaking of which, diff would be a good tool to
compare the two

–
palladium

11

Well … on the contrary it could be interesting!

  • open a terminal window
  • on this page, select the following line with your mouse (by pressing and holding the left button)
    export LC_ALL=C
  • Click inside (or on the title bar … depending on desktop kind and settings) of the terminal window, in order to make it active.
  • now, position the cursor on the command line prompt and press the middle button ( = the wheel ). It should paste the clipboard into the command line.
  • Press enter to run the command!
12

But as he wrote in his first post…

…]e.g.

a paste of
file:///usr/share/applications/kde4/konsole.desktop

becomes
fil:///usr/shar/applications/kd4/konsol.dsktop

on the command line. Weird.

Let’s see what results palladiums hint will have. They sound promising.

13

Ooops ! I didn’t see that. It is weird.
As for ~/.bashrc, unless YaST generates or modifies it on the fly, which I doubt, it should be enough to take a look at /etc/skel/.bashrc. Mine just sources alias and fuctions , don’t enable bash completion and set a a user prompt. I don’t know how it differs from openSUSE default (it possibly might).

what about :
xterm -fn 9x15

Maybe it’s just a bad or broken font.
You can also use xlsfonts to list the available fonts and try them one by one (well … maybe not one by one ;))

14

OK, I cheated - I added your suggestions to the “.bash_history” file then did a “history -r” so I could try those commands by scrolling back through the history and/or using the “!####” (read history line number) command, which work when the command has a letter ‘e’ in them. Here are the results:

~> export LC_ALL=C
~> xmodmap -pk | grep 0065
xmodmap: unable to open display ‘’

~> xterm -fn 9x15
xterm Xt error: Can’t open display:
xterm: DISPLAY is not set

So it appears that maybe the “DISPLAY” setting has something to do with this? :\

Thanks,
Star_Gazer

15

I did try the xterm -fn 9x15 but got the same issue - I also tried other monospace fonts, and that did not work either - maybe my last post may be of some understanding. I think I will just create a different user and move my some of my directories and files into the new created user. I am also thinking about uninstalling xterm and reinstalling it.

Thanks,
Star_Gazer

16

The “unable to open display” error means that you’re trying to run an X application as root while logged in as user. This is normally not allowed for security reasons. Either start xterm as user or, before starting it as root, as user type : xhost +.

If you’re logged in locally on your computer, the DISPLAY value should be :0.0. You can find out with echo $DISPLAY. Normally you don’t have to define this variable while working on the same computer with a single screen. However, if connected through ssh, you would.

17

A many thanks to you all for all your input, effort, and help.

It has certainly been a long day but this evening, the problem is now gone.

Apparently, it has something to do with the ‘.inputrc’ file (at least) - I do not know why, because I had altered it Friday, yet I did not notice a problem until Saturday, so there may be other factors correlated to this.

In that file, I had uncomment the lines:

set bell-style audible

and

end

Actually, the word “audible” was something else before I used it.

When putting the comment mark (#) on the line with “end” on it, the problem went away.

At first, I commented “set bell-style audible”, but that did not solve the problem.

I had made another subdirectory for the home folder, and copied files one at a time into the user directory I have been using normally. The terminal kept working file until I copied the “.inputrc” file into it, thus, that showed me the culprit.

This has all certainly been a very strange and weird ordeal, indeed. I will look into this “.inputrc” file on the other linux distros and try to understand why the word “end” cannot be used it on the openSUSE 11.2 distro, if not the other distros as well.

Thanks to all of you again,
Star_Gazer

18

It is just a comment to indicate the end of the file. If you remove the ‘#’, it get parsed as an instruction … which might have unpredictable results, as you revealed to us.

19

Oh, I understand what you have stated. Very interesting. Perhaps I should change the comment to ‘end of file’ :wink:

20

Star Gazer wrote:
> I had altered it Friday, yet I did not notice a problem until Saturday

i now wonder what drove you into .inputrc (i wonder because having
used linux about ten years i can’t recall ever peeking inside…)

but, just to try to emphasis a point, for future reference:

linux is generally a very stable operating system…when set up
correctly it should stay stable, dependable and predictable (there
are, for example not a great chance it will get strange/slow/etc from
a virus invasion or a packed with crud registry)…

which mean, if suddenly it starts doing strange things then your
FIRST suspects should be the just preceding:

-update
-added program
-hardware flakiness
-user/administrator missteps/typos/mistakes…

so, if you have not added any programs, updates and don’t have reason
to believe hardware errors and suddenly you can’t (for example) type
an ‘e’ then just sit down and think: what did i do in any
config/hidden file since the last time this strange thing didn’t happen?

and, start undoing them…

as a matter of practice what i do here is before i change any config
file i make a copy of what was working, into the same directory…so,
if i typo a crazy it is real easy to find and restore what it used to be…

like, in your case, if i looked in my /home on Saturday when the crazy
began i would have found

~/.inputrc
~/.inputrcBAK2010.02.19

by using the yyyy.mm.dd appendage all changes over time will fall in
order…

if i make several changes in one day i just add a 24 hour time stamp

~/.inputrc
~/.inputrcBAK2010.02.19
~/.inputrcBAK2010.02.19.0924
~/.inputrcBAK2010.02.19.1653

oh, and of course that ‘trick’ to add a new user and see if all is
well, is a wonderfully predictable way to zero in on a problem
somewhere within your own /home…

–
palladium