Skip to content
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

Closed
nincode opened this issue Mar 10, 2021 · 7 comments
Closed

Expose errorlevel / exit code of last command to custom hlsl shaders #9435

nincode opened this issue Mar 10, 2021 · 7 comments
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal.

Comments

@nincode
Copy link

nincode commented Mar 10, 2021

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.

cbuffer PixelShaderSettings {
  float  Time;
  float  Scale;
  float2 Resolution;
  float4 Background;
  int ErrorLevel; // <---- error level of last command
};
@nincode nincode added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Mar 10, 2021
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Mar 10, 2021
@DHowett
Copy link
Member

DHowett commented Mar 10, 2021

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.)

@KalleOlaviNiemitalo
Copy link

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.

@KalleOlaviNiemitalo
Copy link

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.

@zadjii-msft
Copy link
Member

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.

@zadjii-msft zadjii-msft added Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support Product-Terminal The new Windows Terminal. labels Mar 11, 2021
@KalleOlaviNiemitalo
Copy link

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.

@zadjii-msft
Copy link
Member

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...

@nincode
Copy link
Author

nincode commented Mar 12, 2021

This all makes sense, thanks for considering this everyone.
As a compromise, could you please take a look at #9468 ?
The fight for sweet sweet pixel shader backgrounds continues. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

4 participants