MightyPirates / OpenComputers

Home of the OpenComputers mod for Minecraft.
https://oc.cil.li
Other
1.59k stars 430 forks source link

Odd behaviour of 'cat' command in oc computer console #2886

Closed Fictitious-Rotor closed 6 years ago

Fictitious-Rotor commented 6 years ago

I was messing around in an oc computer console and ran

cat > shouldAutorun.property
false

Followed by Ctrl + D to escape the command.

I then typed

cat shouldAutorun.property

To see if it saved correctly. Alas the result was blank, so I went through the aforementioned sequence a second time.

Still nothing - so I typed

edit shouldAutorun.property

And was presented with some very interesting characters, after which I tried to exit the editor.

The following screenshot is what I got after trying to do this. https://imgur.com/a/LhhYZyD

Left me a little confused :)

payonel commented 6 years ago

huh, it appears it is printing the blink, those are the weird characters, to the file. I can look into that Also, ^D closes the stdin file handle, I can also look into having cat flush and finish writing the file when you close it that way.

great finds, thank you

payonel commented 6 years ago

this ONE bug report uncovered various underlying issues and for that i'm quite grateful

  1. when i built the pipe library i then used it in cmd piping as well as the thread library. to my surprise, while debugging this issue, i found that the redirection hacks in the piping layer weren't even being used. this is fantastic, I love removing code to fix a bug. Redirection works completely outside of the piping layer which is great, as it should. I just removed unused code and it is cleaner now
  2. cat was closing the fd it was using when done. this was causing the parent io to close because openos was not using any sort of dup of file handles. I decided it was time, and now we have io.dup, and all processes now dup their parent io. this uncovered a few bugs (i run thousands of units tests), in areas in the kernel were certain assumptions were made. the side effects and refactoring I consider to all be good things, the code is better overall because of this.
  3. the CURSOR, which does the keyboard reading, and the tty echoing, it was using stdout to echo. The problem with that is that in your test program, your stdout was redirected to a file. the cursor i decided should be trying to write its echos to the same stream it is reading from. The tty stream is a rw stream, and it made perfect sense to write to the current stdin stream for echos. Now cursor reads echo, regardless of stdout.