2

In my company we use expect to automate tasks, when ssh'ing into other systems. All our legacy systems run ISO-8859-1 character encoding, while our desktop systems run UTF-8 encoding. Which of course poses certain challenges when ssh'ing from one of our desktops into our legacy systems.

This is easily solved by removing the SendEnv line in /etc/ssh/ssh_config and setting the Gnome terminal character encoding to ISO-8859-1 just before starting the ssh session. This works fine when doing it manually from the command prompt or from a bash script. But when doing it from inside an expect script it fails. It seems like the character encoding either isn't handled at all or is handled incorrectly from within expect, which results in mangled characters when we enter special characters.

Bare bones bash script that works:

#!/bin/bash
ssh user@server

Bare bones expect script that produces the error:

#!/usr/bin/expect --
spawn ssh user@server
interact

The Gnome terminal character encoding has been manually set correctly before executing the two scripts. These two scripts should work identically, by ssh'ing into the server and letting the user enter the password. But the bash script handles character encoding correctly, while the expect script produces mangled special characters.

I assume I'm missing something obvious, but I can't figure out what it is I'm missing.

Edit: We have already tried luit, which doesn't help. It only results in differently mangled characters.

Jens Bang
  • 23
  • 6
  • @Wiking luit doesn't solve the problem. It only results in differently mangled characters. – Jens Bang Jul 09 '18 at 14:23
  • 1
    Does adding `fconfigure stdout -encoding iso8859-1` (and/or similar for `stdin` and `stderr`) to the expect script have any effect? – steeldriver Jul 09 '18 at 16:21
  • @steeldriver It has an effect (I added a line for each of stdout, stdin and stderr). The Danish special characters (Danish has 3 extra letters: æ, ø and å), they display fine on the command line (lower case and the upper case versions). But I have to backspace twice to delete one of them from the command line (one backspace will look like it deletes the character, but they are still there and will be sent when I press enter). And they are not handled well at all in vim: lower case versions look fine, but com with an automatic space after them, and the upper case versions are still mangled. – Jens Bang Jul 10 '18 at 07:38
  • You can try leaving the complex gnome terminal settings alone, and telling tcl the ssh i/o encoding: `fconfigure $spawn_id -encoding iso8859-1`. It should then know how to convert the stream into utf-8 internally, and then again into whatever your system locale is when you interact. – meuh Jul 10 '18 at 14:59
  • @meuh That did the trick! :-) The key was to use $spawn_id (which I, being a total expect-noob, didn't know about :-D ). If you write this up as an answer, I would be happy to accept it. – Jens Bang Jul 11 '18 at 07:27

1 Answers1

0

expect is written, as you know, in the tcl language, and you can look here for information on how it handles internationalisation. Internally, tcl converts characters to utf-8, but assumes all input and output uses the system encoding, namely the locale of your terminal.

To override this for a particular data stream you can use fconfigure on the channel id to specify the encoding to use. The spawn command exposes the created channel by setting the variable spawn_id. (Beware, there is a common mistake where you sometimes need to declare this variable as global, e.g. in a procedure).

For your simple example, you need to tell tcl the encoding of the ssh i/o stream and it should do the necessary conversions for you, without you needing to change the gnome terminal locale in any way.

#!/usr/bin/expect --
spawn ssh user@server
fconfigure $spawn_id -encoding iso8859-1
interact
meuh
  • 3,141
  • 13
  • 22
  • Thank you. As already stated in comments under my question, that did the trick. I have accepted your answer, and I also upvoted it, but since I have less than 15 rep it doesn't show. – Jens Bang Jul 11 '18 at 11:05