Re: bash strangeness with utf-8

Benno Schulenberg wrote: > Then look at a new typescript, and see if that strange 1034h is > still there. If yes, a simple 'set | grep 1034' might find the > variable that contains it. Nothing found doing this grep... As for doing a script, the "1034h" is indeed missing in the plain shell you

Re: bash strangeness with utf-8

Hmm, interesting. I thought that using "env | grep PROM" would show PROMPT_COMMAND's value, but I guess not. Yes, I do have PROMPT_COMMAND set, it appears. However, if I unset it (and even also 'export PS1="foo "' to set PS1 to a simple string), the problem remains. How best to debug this? tcs

Re: bash strangeness with utf-8

Hi Benno, Here is the output from "locale": LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 The following prompt is set in my .bashrc (but the same behavior happ

Re: bash strangeness with utf-8

Benno Schulenberg wrote: > No idea, I use Konsole. Better read man xterm. The strangeness happens in Konsole too (as well as the virtual terminals), so I kind of doubt it's the term's issue... > Okay. So what says a typescript in a blank shell with only LANG > defined? Does the ^[[1034h still

Re: bash strangeness with utf-8

Joe Peterson wrote: > Benno Schulenberg wrote: > > On what terminal are you doing this? To what encoding is the > > terminal set? > > Mainly xterm (version 225, at least in one case). And I have the > utf8 option on. Does this set the encoding to the proper value, > or do I need more? No idea,

Re: bash strangeness with utf-8

Benno Schulenberg wrote: > On what terminal are you doing this? To what encoding is the > terminal set? Mainly xterm (version 225, at least in one case). And I have the utf8 option on. Does this set the encoding to the proper value, or do I need more? But also, I have tried this in the simple

Re: bash strangeness with utf-8

Giraud wrote: > Benno Schulenberg wrote: > > Then try 'env -i bash --noprofile --norc'. If that > > instance of the shell doesn't exhibit the problem, then you > > know for sure it's something in the environment. > > Initially, after entering this plain shell, the problem does not > exist. However

Re: bash strangeness with utf-8

Giraud wrote: > Hmm, interesting. Please don't top-post. > Yes, I do have PROMPT_COMMAND set, it appears. However, if I > unset it (and even also 'export PS1="foo "' to set PS1 to a > simple string), the problem remains. Then look at a new typescript, and see if that strange 1034h is still th

Re: bash strangeness with utf-8

Giraud wrote: > The following prompt is set in my .bashrc (but the same behavior > happens if I do not set it or set it to a simple string, so I > don't think this matters): > > PS1="\[\033[33m\]\h-\u\[\033[36m\] [\w] (\!)\[\033[00m\] " > > PROMPT_COMMAND is not set. Look at your typescript

Re: bash strangeness with utf-8

Joe Peterson wrote: > when using LAN=en_US.UTF-8 (anf we've verified same on > en_GB.UTF-8). Apart from LANG=en_US.UTF-8, what is the rest of your locale? > There are two cases I came up with. If you up-arrow through your > history, hit right-arrow (i.e. going "past" the end - even though > the

bash strangeness with utf-8

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: freebsd6.2 Compiler: i686-gentoo-freebsd6.2-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='free bsd6.2' -DCONF_MACHTYPE='i686-gentoo-freebsd6.2' -DCONF_VENDOR='gentoo' -DLOCALE DIR