-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose errorlevel / exit code of last command to custom hlsl shaders #9435
Comments
I really like this idea, but Terminal has to operate under one critical technical constraint: it actually doesn't know anything about the app that it's talking to. It only sees one program -- cmd, powershell, wsl, whatever shell you're actually using -- and only knows about that one thing. If CMD starts a process and then sets ERRORLEVEL, there's no channel through which it can communicate that into back to Terminal. It makes it nearly impossible to do these things without coming up with an in-band control sequence to "tell" Terminal what happened (which then requires shell support, which then requires some standardization, etc.) |
For local processes, Windows Terminal could perhaps track the exit codes via JOBOBJECT_ASSOCIATE_COMPLETION_PORT. That seems unlikely to work with WSL2 or SSH, though. |
The job-object hack would have another flaw, too: if the shell first runs the requested program, and that exits with an error, but the shell then runs more programs in order to format the prompt, it would be difficult for Windows Terminal to know which of those exit codes is significant. |
Yea, as awesome of an idea as this is, I'm just not sure there's any way to accomplish this in a good cross-platform way. There's a lot of edge cases noted here, with nested shells, wsl, and ssh to consider. Maybe someone someday does come up for a standardized way for a shell to tell the terminal about the return code. If that escape sequence ever does get standardized, we can revisit this idea. |
Perhaps this could instead be tied to the taskbar progress indicator #3004. Expose the state and percentage numbers to the shader. Users could then configure their shells to emit the OSC 9;4 sequence as part of the prompt. |
Huh. Now that's not a bad idea. I wonder how breaking it would be to pass more data to a shader. Like, if we add additional params in v1.8, but someone's got a shader file from 1.6 without those params, is it just going to crash/fail? That would certainly be annoying. Then again, it is an experimental feature... |
This all makes sense, thanks for considering this everyone. |
Description of the new feature/enhancement
Custom HLSL shaders are awesome! They would be even better if they responded to what's happening in the shell. For example, I have a nice smoothly swirling Mandlebrot background in my shell, but I would want to it to turn reddish and swirl angrily when a command errors out. So, I would like to see the errorlevel or exit code of last command exposed to HLSL.
Proposed technical implementation details (optional)
On the HLSL side, expose the error level as one more int in the cbuffer. The issue might be how to get the error level; I don't think there's a generic way of getting that in both Windows and over an SSH connection to, say, Linux. However, the Windows bit seems doable.
The text was updated successfully, but these errors were encountered: