From 7b3c5a13c326c3f9d4d346f8132246c747711365 Mon Sep 17 00:00:00 2001 From: Oliver Schmidt Date: Fri, 19 Aug 2022 23:46:09 +0200 Subject: [PATCH] Fix shell shutdown (?) At least on the alternative hardware, things happen this way: 1. The shell 'exit' command has ptyOut signal outputComplete and terminate. At this point, ptyIn is still blocked up to one second in ReadCharacter - and can therefore not react on outputComplete. 2. The outputComplete handler in ShellCommand sends a zero byte. This makes on the A2 DumpOutput return and the caller send a zero byte. ShellCommand must not return here as ptyIn is still blocked. 3. The zero byte from the A2 has ptyIn return from ReadCharacter, signal userCancelled and terminate. 4. ShellCommand can now return, but it must not send a zero byte, as the A2 is not expecting it - and will therefore later misinterpret it. Maybe the original hardware needs another handling, then differentiation of behavior in shell.go becomes necessary. --- RaspberryPi/apple2driver/handlers/shell.go | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/RaspberryPi/apple2driver/handlers/shell.go b/RaspberryPi/apple2driver/handlers/shell.go index df38961..1db501c 100755 --- a/RaspberryPi/apple2driver/handlers/shell.go +++ b/RaspberryPi/apple2driver/handlers/shell.go @@ -45,12 +45,13 @@ func ShellCommand() { case <-outputComplete: ptmx.Close() comm.WriteByte(0) - return +// return + break case <-userCancelled: fmt.Printf("User cancelled, killing process\n") ptmx.Close() cmd.Process.Kill() - comm.WriteByte(0) +// comm.WriteByte(0) return case <-inputComplete: cmd.Wait()