Weird bash issue

HalJordan · 2015-11-28 03:00:52

I have been using zsh for quite some time, both at work and home. We've recently switched from secluded local installations to a centralized login server(kerberos). The login server doesn't have zsh(yet) so I can't have my default shell set to zsh or it causes issues. I've now noticed that I have a very, _VERY_, odd issue with bash....

The letter 'i' doesn't work. 'I' does, and I can ctrl-v 'i' the same way you can enter a literal tab character. It works in text editors, etc. What's really weird is that when I'm in a graphical terminal emulator and try to copy/paste something that has 'i' in it, they are all skipped, so a git link turns to gt.[work related domain].tld. It's highly frustrating. My .bashrc is the one from .skel, my .inputrc only includes the /etc/inputrc, and it's only happening for my login, not anyone else's.

What have I missed?

jasonwryan · 2015-11-28 04:30:06

Paste the .bashrc on the local and remote machines. What is the output of $TERM on local and remote machines?

HalJordan · 2015-11-28 05:46:36

Work username and hostname have been modified, but nothing else.

The $TERM var on a vt is linux, but in a desktop terminal emulator is xterm

[luser-1@office ~]$ cat .bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
alias ll='ls -lA --color=auto'
PS1='[\u@\h \W]\$ '



[hal_j@home ~]$ echo $TERM
xterm
[hal_j@home ~]$ cat .bashrc
#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
PS1='[\u@\h \W]\$ '

Last edited by HalJordan (2015-11-29 01:21:38)

HalJordan · 2015-12-01 06:35:50

A bit of further info in case it's not clear, this is happening only on my user in any instance of bash, but not for any other user. And it happens with different keyboards. It's happening both in avt, and in various desktop terminal emulators, but the letter works properly in everything else (vi, nano, chrome, atom, kate, etc).

drcouzelis · 2015-12-02 13:59:15

What operating system are you using? What is the version of Bash ("bash --version")?

If it's not a hardware (keyboard) issue, and if you are the only person experiencing this problem, then it has to be either a configuration file problem or a permissions problem.

Are you able to create a new user on this system? Does the new user experience the same broken Bash behavior?

Double check permissions, and that the correct permissions, user, and group are set on all files in your home directory, including the home directory itself.

There are other files that affect the Bash environment. See the "FILES" section in the Bash man page.

Are you using the same version and installation of Bash that the other users are using?

Last edited by drcouzelis (2015-12-02 14:00:17)

vacant · 2015-12-02 14:17:18

I think I had a similar problem some time ago, I think LANGUAGE env variable was not set properly.

Last edited by vacant (2015-12-02 14:19:14)

HalJordan · 2015-12-03 00:34:58

@drcouzelis ... What other os would I be using? This is the Arch forum, if I was doing this on Ubuntu, I'd be posting to the Ubuntu forum.

luser@host ~ % bash --version
GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I fully agree with you on the configuration point, I just have no idea what would be causing it that I haven't already checked. I can't create new users at work, but at home it's only for my user. The bash version is the same, they based the template we're using on the workstations on Arch. We're currently working on getting everyone using the template(just started rolling it out last week, till now we've all had our own installs either on a flash drive or hd(I brought an hd from home)).

@vacant I checked and the LANGUAGE variable on all users I can get to/create is unset.

drcouzelis · 2015-12-03 15:43:33

HalJordan wrote:

What other os would I be using?

I'm so confused... So, if I understand correctly:

You have an up-to-date Arch Linux computer that you use at home. You also have an up-to-date Arch Linux server that you log in to at work. On both systems, when you start using Bash (whether it is a TTY or X terminal emulator or ssh or anything else), the command line does not accept the letter "i", neither from your keyboard nor pasted, but the letter "i" IS accepted in terminal applications, such as Nano.

...Is that correct?

HalJordan · 2015-12-12 02:53:39

That's functionally correct. It's not a server at work, but my actual workstation. And (i have no idea what this is actually called, but i go by "inserting the literal") hitting ctrl-v before hand, the same way you can insert a tab character or new line without bash trying to tab complete or execute what's currently entered, and the i goes through just fine. i.e. when typing the word "linux" normally what shows on the screen is "lnux", but if I type "l" "ctrl-v i" "nux" I get the full word on the screen. It's got me totally baffled...

danielgreve · 2015-12-22 07:29:16

Are all of your locale settings correct?

https://wiki.archlinux.org/index.php/Locale

HalJordan · 2015-12-26 03:19:32

They look the same as my coworker, who doesn't have this problem.

[luser@host ~]$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

jasonwryan · 2015-12-26 04:48:56

That is off: it should be en_US.UTF-8

HalJordan · 2015-12-26 22:14:50

His was exactly that, including the case. Only I see this problem.

jasonwryan · 2015-12-26 22:16:24

So, because his locale is broken, you will insist on not fixing yours, simply because he isn't experiencing the same symptoms?

HalJordan · 2016-01-05 02:54:17

I'm trying to fix one thing at a time. That problem obviously isn't causing these symptoms, or I wouldn't be the only one to see it. In fact, no-one here has the locale changed in their bash profiles, and, that's what's showing in our available locales list:

127 luser@host ~ % locale -a
C
en_US
en_US.iso88591
en_US.utf8
POSIX

Arch Linux

#1 2015-11-28 03:00:52

Weird bash issue

#2 2015-11-28 04:30:06

Re: Weird bash issue

#3 2015-11-28 05:46:36

Re: Weird bash issue

#4 2015-12-01 06:35:50

Re: Weird bash issue

#5 2015-12-02 13:59:15

Re: Weird bash issue

#6 2015-12-02 14:17:18

Re: Weird bash issue

#7 2015-12-03 00:34:58

Re: Weird bash issue

#8 2015-12-03 15:43:33

Re: Weird bash issue

#9 2015-12-12 02:53:39

Re: Weird bash issue

#10 2015-12-22 07:29:16

Re: Weird bash issue

#11 2015-12-26 03:19:32

Re: Weird bash issue

#12 2015-12-26 04:48:56

Re: Weird bash issue

#13 2015-12-26 22:14:50

Re: Weird bash issue

#14 2015-12-26 22:16:24

Re: Weird bash issue

#15 2016-01-05 02:54:17

Re: Weird bash issue

Board footer