when I tell the program to get detailed information with the turtle.getItemDetail(1,true) command it crashes with no return or error

What are you getting the item detail of?
What version of the mod are you one?

im getting the item detail of an Immersive Engineering core sample
mod version 1.16.4-1.95.0

Can you try reproducing with 1.95.1 I doubt that it will fix it but just in case.
And if you are willing, checking it on MC 1.15 will help check if it's a version-specific bug.

Hey, would you be able to fill out the issue template? It should have shown up when you created this issue, but I guess GitHub was being a little buggy.

It'd be really useful if you could also describe exactly what the error was? When you say "crashes", does the whole game crash or do you just get an error in the computer? If the latter, what does the error say?

Minecraft version: 1.16.4
CC version: 1.95.0
I dont currently have access to the logs

reproduction steps: I typed these 2 lines of code and get the problem

local data = textutils.serialize(turtle.getItemDetail(1,true))
print(data)

press ctrl in the editor and select run.
the program in the computer crashes without giving an error or do anything and boots you back to the editor. Upon further inspection, the program does actually run correctly outside of the editor, so its not as big of a deal as I had initially thought.

Right, what's going on here is that the program finishes running and so the multi-shell tab is closed. This isn't technically a bug, but definitely not ideal.

I'm not sure what the correct solution is here. We currently have some logic if that a tab won't be automatically closed if it's never been looked at, but as edit focusses a tab immediately that's not much help.

Maybe a better heuristic would be something like "did the program take less than 10 seconds"?

Yes the program executed and then went back to the editor almost instantly. I'd say it was less than a quarter of a second, and nothing on the run screen had any time to load before you are booted back to the editor

A lazy solution for now would just be to put a sleep(5) at the bottom of the program. Though that won't help if the program errors...

WRT the above, when we fix this, we should always keep the tab open if the program errors. I guess we'd need to change shell.lua PROGRAM ARGS... to error if the underlying PROGRAM errors, and then get multishell to handle that properly.

Maybe multishell should wait for explicit closes anyways? But then the opening program would have to be notified that the program that it opened has ended so that it can close the tab if it wants.

Edit: I might be forgetting how multishell works, does it return after opening the program or wait until it ends?

Maybe multishell should wait for explicit closes anyways?

I think the question here is "what is an explicit close"? If I press "exit" in a program (paint, shell, etc...) I'd expect the shell to close automatically without any further interaction. But perhaps not for programs which don't have any user interaction.

Maybe the correct thing to do is treat programs run using edit differently to normal programs - running them through a wrapper which always shows the prompt.

Can a program close its own tab? maybe those programs could do that?

You cannot close a tab prematurely (which IMO is the correct behaviour). Only way to do that is for the program to exit.

Could a program be able to mark itself as close on exit? So the new default behaviour would be that multishell keeps the tab open but multishell has a new function that allows programs to request multishell to close the tab for it once the program exits.

Yes, but then every program which wants that behaviour needs to have some sort of if multishell and multishell.pleaseCloseMeThankYouVeryMuch then multishell.pleaseCloseMeThankYouVeryMuch(). Sure, it's a solution that works, but it's definitely an ugly one.

I suppose if it's press any key to close they could do os.queueEvent("key") which is also blegh

Why not just when program is ran from editor add middleman program that would be between the shell and ran program that would handle displaying errors and such?

Why not just when program is ran from editor add middleman program that would be between the shell and ran program that would handle displaying errors and such?

this seems like the ideal behavior.
the editor should run the program through a wrapper to allow the "press a key to close" to always work.

I use something similar to the following:

... = coroutine.create(function()
    local s, m = run(program) -- some run method that returns code + msg
    if not s and m and m ~= 'Terminated' then
        print(m)
        print('press enter to close')
        while true do
            local e, code = os.pullEventRaw('key')
            if e == 'terminate' or e == 'key' and code == keys.enter then
                break
            end
        end
    end

Only waiting for a key if the program did not exit gracefully.