1

I am using SSH to connect to a server, where on occasion I need to work with some right-to-left language (e.g. Arabic).

When I use some console software (e.g. lxterminal or xfce4-terminal), it works out just fine. In other terminals the text is backwards. Moreover, this behaviour is not even consistent across different computers (the xfce4-terminal behaves differently at home and in my office).

What's worse is that the terminals are fine. Local files are displayed correctly. It is only when I connect via SSH that the problem occurs.

So... what's the problem? Where is coming from? Is it the SSH, or the terminal, or somehow both?

Improve this question

1 Answer 1

Reset to default
2

What's worse is that the terminals are fine.

I doubt so. This is a much more complex story than you probably think. Terminals behave differently, and one's behavior might be right-to-left friendly with a certain set of applications, while others' behavior might be RTL friendly with another set of apps.

Local files are displayed correctly.

Again, it highly depends on what you mean by "displayed": do you cat them, or open with vim, emacs, less, some other application, etc. Maybe with some terminals cat gives the expected result and vim the unexpected one, with other terminals the other way around.

You might be interested in this, an about 50-page long technical document studying the situation and proposing a way to address the problems, so that a terminal can support multiple modes, and as such support the seemingly contradicting requirements of different kinds of apps.

VTE version 0.58 implements the proposed solution. VTE is the terminal emulation engine used by lxterminal and xfce4-terminal, along with many other terminals. Whether you see the "good" or "bad" behavior in these software might thus easily depend on VTE's version. However, again, it's possible that you find the old behavior the "good" one and the new the "bad", depending on what types of applications you test with. In this case, with VTE >= 0.58 you can use the escape sequences mentioned in the document to switch mode, e.g. printf "\e[8l" to revert to the old behavior.

ssh is irrelevant, apart from a software's local or remote version possibly being different.

Improve this answer
5
  • At home I'm using Arch, and I have vte and vte3 installed. It seems that the latter is 0.60, and the former is not. I suppose that means that the difference in terminal behaviour comes from difference in underlying engines? (I've removed the vte package, but things are still working as they used to an hour ago...) Commented Apr 25, 2020 at 17:29
  • A terminal can either use vte or vte3 depending on its source and maybe compile time options, it's never a runtime decision. Check the dependencies in the package manager, or echo $VTE_VERSION (empty for the former, the version number as 6000 or so for the latter). Commented Apr 25, 2020 at 20:22
  • Both terminals have vte version 6002. Commented Apr 28, 2020 at 7:54
  • You've taught me here to always give up on my hopes for a uniform and consistent behaviour of bidi text in consoles. But thank you very much! Commented Apr 28, 2020 at 17:57
  • 1
    "Hope is not a strategy". Do you want uniform, consistent bidi in terminals and apps? Study my work, send feedback, encourage (ahem sponsor ahem) me to finally finish writing up v0.2 of the doc. Then v0.3 which handles BiDi control chars, along with its implementation in VTE. Work on getting other terminals and terminal-based apps adapt to this spec, by filing bugs, comments, creating patches etc. Or, of course, you can still "hope" (or give up that hope), but that won't move us forward. :-) Commented Apr 28, 2020 at 20:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.