search

dan200 / ComputerCraft

Programmable Computers for Minecraft
Other
977 stars 198 forks source link

[Bug]term.redirect() does not work in Programs #423

Closed JakobDev closed 6 years ago

JakobDev commented 7 years ago

How to reproduce: Create a new file and just add this code: "term.redirect({})". Now run the file. You will see that nothing happened. If you run this code in the LUA Shell CraftOS will crash, but in a Program, it does nothing.

Lupus590 commented 7 years ago

That's not a valid terminal object, but an error would be might be more helpful.

SquidDev commented 7 years ago

This is because term.redirect({}) on it's own isn't invalid. It only becomes invalid when you try to do something with it.

When you're running in the Lua prompt, it'll redirect to this invalid terminal, and then try to write the return value using this invalid object - hence the crash.

Meanwhile in the shell, it'll just redirect to the original terminal again, and so no error occurs. If you try to write something in the program, then you're going to get issues.

I don't personally see this as a bug, it's just #332 surfacing again - how much validation does one do "on the fly" and how much does one do on the initial call to term.redirect. I guess you could check the table isn't entirely empty, but I'm not sure it's worth the hassle.

Lupus590 commented 7 years ago

Perhaps #396 could include a warning about term objects and point to the wiki (Or ingame help docs) when the function is called.

BombBloke commented 7 years ago

I suspect that Wilma's not complaining about the lack of a crash (... this time), but rather that the shell doesn't continue to use whatever terminal a script last redirected to? Certainly using term.redirect() within a script "works", but it's also true that running his example code has "no effect".

This is intended behaviour (or at least, Dan appears to've gone out of his way to implement it), and it's my personally preferred behaviour - older versions of ComputerCraft didn't auto-redirect back, and it was a royal pain having to do it manually. When debugging scripts that'd crashed before doing it themselves, you'd typically be typing away without the ability to see the commands you were entering.

dan200 commented 6 years ago

Yep.. you don't want a program to permanently wreck the terminal for subsequent programs.