That darn pipe symbol?

English Applications
#1

Sorry to keep banging on about this problem, but I hate letting this vindictive computer get the better of me!

If I ask the question in a different way, maybe it will trigger a few neurons somewhere? Here goes …

If I take four different display routes on to this SuSE 11.1 box, I get different results. Why? Now it seems that from the little research that I have done, that this is a particularity thorny topic, so if I am using the wrong terminology, forgive me.

Base conditions: Desktop manager (when applicable is KDE 4), keyboards are UK styles and the same user login in each case.

To make sure that I am not confusing the “|” (pipe, 0x7c, 124) symbol with the “¦” (broken bar, 0xa6, 166), I will use the simple test of piping to grep, like this:cat /etc/motd ¦ grep -v “fun”. If it is not the pipe symbol, grep will not be called and the motd will be printed.

a) telnet. FAIL - its a “¦”
b) putty. PASS - its a “|”
c) xrdp/mstsc. In Konsole FAIL - its a “¦”
d) hardware console. In Konsole PASS - its a “|”

Help! Where do I look to resolve this?

Best regards, Martin

#2

Hi
You might want to look at the TERM environment variable. Thin putty
uses vt100? You could try an export of either xterm or vt100.


env |grep TERM
or;
echo $TERM
then;
export TERM=vt100
or
export TERM=xterm

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.39-0.3-default
up 2 days 23:52, 3 users, load average: 0.14, 0.09, 0.06
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

#3

And the systems you type from may not all be UTF-8 capable (just a guess).

#4

Thanks for the suggestion Malcom,
BUT, in all the quotes cases, the $TERM environment variable is “xterm”. Additionally, changing it to “vt100” does not change the display character.

Regards, Martin

#5

The remote system is the same in all three cases.

Oh, and one more test that I’ve just thought of.
If I logon the the hardware console, the pipe character displays/functions correctly.
Additional, from that same hardware console, if I rdesktop localhost, I also get a working pipe symbol.

This seems to confirm your suspicion that the problem is at the “remote” end? I’m going to investigate the “may not all be UTF-8 capable” angle.

Regards, Martin
PS - Any thoughts on how I can do that …?

#6

You ask how. Do not know exactly. My brain is just slowly starting on this, maybe I missed something.

That telnet case. Does it mean you telnet from systema to systemb and then send a command containing a “|” and the command arrives at the other end having a “¦”? How about starting vi (in that telnet session) and inserting a line with a “|”. As vi is UTF-8 consious by default.

#7

martinprowe wrote:

> a) telnet. FAIL - its a “¦”
> b) putty. PASS - its a “|”
> c) xrdp/mstsc. In Konsole FAIL - its a “¦”
> d) hardware console. In Konsole PASS - its a “|”
>
> Help! Where do I look to resolve this?
>
> Best regards, Martin
>
Perhaps a Alt Gr ` (backtick) works i.e. |

#8

Thanks Graham,

But nope! That produces the broken bar as well.

#9

Hi HCVV(?),

Yes, I telnet from System_a to System_b. I am now in a bash shell (I think), if I then hit the pipe key (on my UK keyboard, it is left of the “z” key), I see a broken bar displayed on the screen. The telnet session is in key-by-key mode, so I am assuming that there is no translation by System_a before being sent to System_b. I am trying to find out what code is in fact being sent between System_a and System_B now.

In your second question, running vi in the telnet session. Same results as above. If I hit the pipe key, I see a broken pipe in vi.

#10

I see what you mean. I can not help with recreating it here. I have an US keyboard. There is a key left from the zZ and it does <> (for which I use normaly keys right from mM) but the characters on it are | (I never ever used that key before). I also have a key right from the lL (with ;: and '" in between) that says also and does |. That is the one I normaly use for a pipe.

IIRC there is some program that shows you the key-codes (not the ASCII or Unicode) generated when a key is hit. Found showkey(1) with google, but it was another one. At least

showkey -a

shows you the ASCII codes.

BTW you have a UK keyboards, but is your system aware of it?

PS the name is Henk, but the acronym for my full name Hendrik Cornelis van Velden is OK.

#11

Been looking at this again. And I need to apologise - I have given you false info.

For the record. If I Telnet from System_a (Win XP) to System_b (SuSE 11.1)and hit the pipe key, using Wireshark, I can see that the Unicode/UTF-8 code (U+007c) is sent from Sys_a to Sys_b. Then Sys_b sends it back (echo) to Sys_a which displays it as a broken bar.

However, this does not matter as the correct code has reached the Linix shell and gets executed correctly. From this I conclude that the Telnet connection is working as it should and the only miscreant mode is System_a to System_ via an RDP connection.

However, that is where I started and that is what I am trying to fix. Unfortunately, the data format in the RDP traffic is not as easy to see as the Telnet traffic, which prevents me from using the same technique to asign the fault to System_a or System_b.

But as the rdp client is in very wide use to MS terminal servers and this pipe problem has not been recorded anywhere that I have seen, my suspision is that the problem is at the System_b end (SuSE/XRDP)?

I hope that the above is not to convoluted and that you have not lost interest.

Best regards, Martin

#12

I have not lost interest, but I must add that I have almost no knowledge of MS Windows nor of any telnet client that can be used there.

When the | arrives at Sus_b correct (as you can prove), it will most probably be echoed back by the telnet server as it is (but you did not prove it). Can you type characters into that client without them being send to Sys-b, like local comands? Then yoou could see how it displays the | when not echoed from remote.

#13

Hi Henk,

Before I forget, thank you very much for the “showkey” tip. That is very useful. Another utility that I found is xev. That also gives the up/down codes.

I am now almost certain that the client (system_a - be it Win or Linux) is not the culprit. All non-rdp sessions that I can think of test out okay.

I have mailed the author of the XRDP package to ask for his help. If I get a solution, I’ll mail back for others.

If you are still looking for a challenge? I still need a workaround (just in case!). I am sure that there is a way of “composing” the pipe symbol - something along the lines of the AltGr+(tick) tip proposed earlier in this thread. I have read a lot about “dead keys” and COMPOSETABLE=
If you have any tips in that area, I’d be more than pleasd to hear from you.

Thaks again Henk,
~Martin

#14

The dead keys and the Compose key are for letting one to type characters that are not on the keyboard, but | is.

Mostly they are used for accented characters. You type then first the ’ and then the e to get é. But more excotic combinations do work also s and s to get ß. And ^ and 1 to get ¹.

The dead keys are ‘always’ on and thus when you need a ', you have to type ’ and '. The Compose key starts one dead key sequence.

Dead keys are inherent to a keyboard model. As you may have seen I am dutch. We do not need many accented characters for dutch, but we use french loan words which still have them. Incredible enough the best way to have dead keys fitting for dutch one should use the Portugese (Brazilian) keyboard model (with the US english keyboard hardware). I use the US keyboard hardware with the US-english keyboard model and defined a Compose key. Personal taste.

#15

martinprowe wrote:

>
> graham;2091894 Wrote:
>>
>> Perhaps a Alt Gr ` (backtick) works i.e. |
>
> Thanks Graham,
>
> But nope! That produces the broken bar as well.
>
>
I’ve noticed that Alt Gr \ gives a pipe | and Alt Gr Shift
give a broken pipe ¦. Any clues from that information?