tests/fkr.expect


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

# vim: set filetype=expect:

spawn $fish_key_reader -c

# Do we get the expected startup prompt?
expect -ex "Press a key" {
    puts "saw expected startup prompt"
} unmatched {
    puts stderr "didn't see expected startup prompt"
}

# Is a single control char echoed correctly?
send "\x01"
expect -ex "char: \\cA\r\n" {
    puts "ctrl-a handled"
} unmatched {
    puts stderr "ctrl-a not handled"
}

# Is a non-ASCII char echoed correctly? This looks a bit odd but \xE9
# when using UTF-8 encoding becomes the two byte sequence \xC3\xA9 (or
# \303\251).
send "\xE9"
expect -ex "char: \\303  (aka non-ASCII)\r\n" {
    puts "\\xE9, first byte, handled"
} unmatched {
    puts stderr "\\xE9, first byte, not handled"
}
expect -ex "char: \\251  (aka non-ASCII)\r\n" {
    puts "\\xE9, second byte, handled"
} unmatched {
    puts stderr "\\xE9, second byte, not handled"
}

# Is a NULL char echoed correctly?
send -null
expect -ex "char: \\c@\r\n" {
    puts "\\c@ handled"
} unmatched {
    puts stderr "\\c@ not handled"
}

# Does it keep running if handed control sequences in the wrong order?
send "\x03\x04"
expect -ex "char: \\cD\r\n" {
    puts "invalid terminate sequence handled"
} unmatched {
    puts stderr "invalid terminate sequence not handled"
}

# Now send a second [ctrl-D]. Does that terminate the process like it should?
send "\x04"
expect -ex "char: \\cD\r\n" {
    puts "valid terminate sequence handled"
} unmatched {
    puts stderr "valid terminate sequence not handled"
}
expect -ex "Exiting at your request.\r\n" {
    puts "exited on seeing valid terminate"
} unmatched {
    puts stderr "did not exit on seeing valid terminate sequence"
}