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.

6 files changed, 77 insertions, 0 deletions

diff --git a/src/fish_key_reader.cpp b/src/fish_key_reader.cpp
index 0051ebb4..72d550c2 100644
--- a/src/fish_key_reader.cpp
+++ b/src/fish_key_reader.cpp
@@ -281,6 +281,11 @@ int main(int argc, char **argv) {
         return 1;
     }
 
+    if (!isatty(STDIN_FILENO) || !isatty(STDOUT_FILENO)) {
+        fprintf(stderr, "Stdin and stdout must be attached to a tty, redirection not allowed.\n");
+        return 1;
+    }
+
     setup_and_process_keys(continuous_mode);
     return 0;
 }
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
diff --git a/tests/fkr.expect.err b/tests/fkr.expect.err
new file mode 100644
index 00000000..e69de29b
--- /dev/null
+++ b/tests/fkr.expect.err
diff --git a/tests/fkr.expect.out b/tests/fkr.expect.out
new file mode 100644
index 00000000..fdda2047
--- /dev/null
+++ b/tests/fkr.expect.out
@@ -0,0 +1,8 @@
+saw expected startup prompt
+ctrl-a handled
+\xE9, first byte, handled
+\xE9, second byte, handled
+\c@ handled
+invalid terminate sequence handled
+valid terminate sequence handled
+exited on seeing valid terminate
diff --git a/tests/fkr.expect.status b/tests/fkr.expect.status
new file mode 100644
index 00000000..573541ac
--- /dev/null
+++ b/tests/fkr.expect.status
@@ -0,0 +1 @@
+0
diff --git a/tests/interactive.expect.rc b/tests/interactive.expect.rc
index b0cc9e89..5900f537 100644
--- a/tests/interactive.expect.rc
+++ b/tests/interactive.expect.rc
@@ -4,6 +4,7 @@ log_user 0
 log_file -noappend interactive.tmp.log
 
 set fish ../test/root/bin/fish
+set fish_key_reader ../test/root/bin/fish_key_reader
 
 set timeout 5