From d7bc20c93311fcda1e8548a121db1bdf769dec87 Mon Sep 17 00:00:00 2001
From: Kurtis Rader <krader@skepticism.us>
Date: Sun, 26 Jun 2016 21:47:36 -0700
Subject: don't allow f-k-r to run if stdin/stdout not a tty

Another developer noticed that redirecting stdin of `fish_key_reader`
results in weird behavior.  Which is not at all surprising. So add checks
to ensure stdin and stdout are attached to a tty.

Add some rudimentary unit tests for this program.
---
 tests/fkr.expect | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 tests/fkr.expect

(limited to 'tests/fkr.expect')

diff --git a/tests/fkr.expect b/tests/fkr.expect
new file mode 100644
index 00000000..1f2c3a3a
--- /dev/null
+++ b/tests/fkr.expect
@@ -0,0 +1,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"
+}
\ No newline at end of file
-- 
cgit v1.2.3