aboutsummaryrefslogtreecommitdiff
path: root/client/acronc/main.c
AgeCommit message (Collapse)Author
2022-07-27feat(acronc): add Windows supportTrumeet
2022-07-27feat(acronc): add id and host to the promptTrumeet
Signed-off-by: Trumeet <yuuta@yuuta.moe>
2022-07-26feat(acronc): prettify cli experienceTrumeet
1. Make SIGINT interrupt the current operation by forcing stdin to listen again (because the spec currently does not specify how to send the final response, so acronc will wait forever in case of invalid commands) 2. Prettify prompt and output. Signed-off-by: Trumeet <yuuta@yuuta.moe>
2022-07-26fix(acronc): input <cmd><EOF> will cause illegal memory accessTrumeet
Cause: 1. stdin got cmd -> request 2. stdin got EOF -> ac_disconnect -> ac_conn becomes NULL 3. socket got response -> ac_receive(ac_conn) -> crash Conclusion: ordering issue between ac_disconnect and socket read. Solution: Best way: pause the input until command returns Cons: 1. Lost the advantage of background execution of commands (has to wait until done) 2. It is unreliable to determine if a command is done: although the current server implementation will not send anything else after an error or cmd_result, Minecraft server itself or future server implementations may. The spec does not say anything on termination. Acronc currently assumes that after receiving an error or cmd_result with the same request ID, it is done. Then, it resumes the stdin, reads the EOF, and then disconnect. Worse way: Directly call uv_read_stop before ac_disconnect Cons: It is going to lose anything, including command results. This is particularly undesirable for ad-hoc calls (i.e. echo list | acronc). Therefore, the current approach is to block and read as much as we can (until error or cmd_result), then stop reading the socket before disconnecting as a double safe. Signed-off-by: Trumeet <yuuta@yuuta.moe>
2022-07-26fix(acronc): code cleanupTrumeet
Signed-off-by: Trumeet <yuuta@yuuta.moe>
2022-07-26refactor(libacron/acronc/helloworld): move to separate directoriesTrumeet
The corresponding CMakeLists.txt files are still rough.