Questions[expect](ubuntu)

I have connected to a port like this:

nc hello-world.mygame.com 2000

which opens a small game like this:

Please enter your name
a
hello a,

Now I know that a specific number of repeated "a" 's will give special output, how can I iterate over them easily (a then aa then aaa and so on) to get to that special output?

My first try:

awk 'BEGIN{for(i=1; i<=30; i++){s=s "a"; print s}}' | nc hello-world.mygame.com 2000

But it only submits a as input, how can I let it wait for others? I don't know how to use expect here?

My second try:

for x in a aa aaa; do echo $x | nc hello-world.mine.com 2000 done

I'm trying to automate the pairing of my headset to my ubuntu16 machine.

I took this nice script and tried it, but it didn't work. I played around a bit, and found out that I can just work with this minimal script:

#!/usr/bin/expect -f

set prompt '#'
set address [lindex $argv 0]

spawn bluetoothctl &> /dev/null
expect -re $prompt
send "\nconnect <my_mac_addr>\r"
sleep 10

I save this as a ./bluetooth.sh and run it with ./bluetooth.sh & and it works like a charm. However, I get this annoying bluetoothctl output:

[NEW] Controller *** ### [default]
[NEW] Device *** A
[NEW] Device *** B
[NEW] Device *** C
[bluetooth]# 

I tried removing it with the redirection I added to the spawn command, but it didn't help as you can see...

Removing the expect would work, but I'm not sure this is the way to go...

I'm writing a script that automatically enters the user's input for an openssl command, but I can't find a way of entering the required passphrase automatically by the script. What I've tried:

spawn sudo openssl x509 -req -in client.csr -CA /etc/mosquitto/ca_certificates/ca.crt -CAkey /etc/mosquitto/ca_certificates/ca.key -CAcreateserial -out client.crt -days 15; 
expect 'Enter pass phrase for /etc/mosquitto/ca_certificates/ca.key:'
send '1234\n'

Doesn't work (spawn and send not found)

printf '1234\n' | sudo openssl x509 -req -in client.csr -CA /etc/mosquitto/ca_certificates/ca.crt -CAkey /etc/mosquitto/ca_certificates/ca.key -CAcreateserial -out client.crt -days 15; 

Doesn't work, stays waiting for the passphrase and programs never finishes, unless I enter '1234' manually.

In other cases, it works with printf:

printf 'ES\n\n\n\n\nclient'$n'\n\n\n\n' | sudo openssl req -out client.csr -key client.key -new; 

My guess is that printf doesn't work if the input it's hidden. Any ideas?

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.

I find the "unbuffer" command very important and useful, because I am running python code, and I don't think I can just put something equivalent to fflush() everywhere.

I used to use it just fine: unbuffer python foo.py | tee filename.log

A few months ago, I'm not sure if I had allowed my Ubuntu 16.04 to auto update some software, and it stopped working.

$ unbuffer
can't find package Expect
    while executing
"package require Expect"
    (file "/usr/bin/unbuffer" line 6)

I tried editing some files and changing Expect to lower case expect but it didn't work.

I tried (months ago) using apt-get tools to uninstall and reinstall Expect, but to no avail. I'm surprised I can't google this and find others complaining about it not working.

I just tried it on a friend's 18.04 Ubuntu. He has never used it, he downloaded it with apt-get and gets the same failure message. Any help appreciated.

Thanks @pynexj for the suggestion to cat /usr/bin/unbuffer:

#!/bin/sh
# -*- tcl -*-
# The next line is executed by /bin/sh, but not tcl \
exec tclsh8.6 "$0" ${1+"$@"}

package require expect


# -*- tcl -*-
# Description: unbuffer stdout of a program
# Author: Don Libes, NIST

if {[string compare [lindex $argv 0] "-p"] == 0} {
    # pipeline
    set stty_init "-echo"
    eval [list spawn -noecho] [lrange $argv 1 end]
    close_on_eof -i $user_spawn_id 0
    interact {
    eof {
        # flush remaining output from child
        expect -timeout 1 -re .+
        return
    }
    }
} else {
    set stty_init "-opost"
    set timeout -1
    eval [list spawn -noecho] $argv
    expect
    exit [lindex [wait] 3]
}

I have been using conda on this machine, but I'm running these tests in a terminal where I have not done any source activate. The first item in my path is /home/myusername/anaconda3/bin , if that matters.

$ apt list --installed | grep -i expect

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

expect/xenial,now 5.45-7 amd64 [installed]
python3-pexpect/xenial,xenial,now 4.0.1-1 all [installed]
tcl-expect/xenial,now 5.45-7 amd64 [installed,automatic]

$ locate '*expect*pkgIndex.tcl'
/usr/lib/tcltk/x86_64-linux-gnu/expect5.45/pkgIndex.tcl

Thanks @glenn jackman, I found that my tclsh is in ~/anaconda3/bin/tclsh and points to tclsh8.6 I guess this means it was installed as part of my conda installation. As noted above, anaconda3/bin is at the top of my PATH. I haven't built anything myself.

Do we know if 8.6 is old or new? Should I try to do a apt-get update on tcl or tclsh, outside of conda stuff, and see if that helps?