Enpoint Log gets cluttered with hard to read ANSI escape sequences from scrips, which cannot be suppressed
Enpoint Log gets cluttered with hard to read ANSI escape sequences from scrips, which cannot be suppressed
I use Invoke-PSUScript to start jobs from endpoint calls, and frequently use the Log tab in the endpoint code editor for debugging or traceback etc.
Sadly this log is hard to read for 2 reasons:
1) it does not support ANSI sequences, but still displays them as text.
2) return values from Invoke-PSUScript do get written in the log, even if they are captured.
So a simple $DisplayName = Invoke-PSUScript -Script 'getUser.ps1' -Wait
sould not write the return value itself to the log, since it is captured in a variable, but it still does and on top all outputs (return / write-Information, etc) of that script contain ANSI sequences:[Information] [Api-/data/getUser:GET] [32;1mDisplayString : [0mJohn Doe
So I would love to either have the log support those ANSI sequences or have it stripe them off.
Also, captured return values from scrips should not appear in the log, which would be consistend to the powershell behavior in general.
All Comments (3)
@tools-sebi I've opened an issue for this to improve this. We might be able to just reuse the same UI that the job log uses to properly render the output. As for the captured value being printed, that is another issue and has been mentioned before, especially when users are running child jobs because it makes the parent job log look very messy. I've opened a separate issue for that because it's a bit more of a complex fix.
Adam Driscoll
PowerShell Expert and Software Architect at Devolutions
@tools-sebi I've opened an issue for this to improve this. We might be able to just reuse the same UI that the job log uses to properly render the output. As for the captured value being printed, that is another issue and has been mentioned before, especially when users are running child jobs because it makes the parent job log look very messy. I've opened a separate issue for that because it's a bit more of a complex fix.
@Adam Driscoll
Just checking, if there is already an update to this, which i might just have missed :)
@tools-sebi Apologies for the delay on this one. We've just merged a fix for 2026.3.3 so keep an eye out for that version.
Adam Driscoll
PowerShell Expert and Software Architect at Devolutions