Closed archbirdplus closed 7 months ago
Regarding option 1: We could detect if the script was run by double clicking or not (https://stackoverflow.com/questions/9419875/determining-if-batch-script-has-been-started-executed-from-the-command-line-cmd/9422268#9422268) and only then call read. Not sure how reliable this works for other terminals, like for example the VSCode builtin terminal.
Linux may be able to abuse ps
and $SHLVL
if double-clicking behaves differently. MacOS, however, just opens a terminal window with /path/to/script ; exit
, which should not be detectable at all.
As many people (as per the official instructions) open the
run_release
script from the OS file-opening gui, the script closes upon completion, deleting the error messages. Tech support then has the user run the script in an existing shell to access error logs.Key issue:
run_release
exits and destroys error logs when executed from a gui.Option 1: Call
read
or equivalent if the Cubyz executable is not generated or zig exits with non-zero exit code. This prevents the window from closing. Side effect: forces power users to press enter unnecessarily.Option 2: Detect if the shell will close if the script exits, then proceed to Option 1. This may not be possible.
Option 3: Create another script, like
run_release_gui
, for running from gui, then proceed to Option 1. See also points 1. and 2. of #241 about renaming the scripts. Side effect: extra complexity.Option 4: Pipe/redirect/
tee
all logs from the script intologs/log123.txt
, for example. Side effect: terminal colors do not always play nice with pipes.I have no doubt there is a better solution, though.
This issue stacks with #241, which brings up script renaming and extra logging.