You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows 10 I see unexpected output in one of our tests. I do not see this extra output on Linux.
Perhaps there's some obscure bug in our code but we don't have anything that obviously emits such a strange combination as \r\u0008.
What version of Go are you using (go version)?
go version go1.17.1 windows/amd64
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
What did you do?
git clone https://github.com/microsoft/go-sqlcmd
go test -json ./...
The text was updated successfully, but these errors were encountered:
changed the title
Spurious linefeed + backspace (\r\u0008) characters in go test output on Windows
cmd/go: spurious linefeed + backspace (\r\u0008) characters in go test -json output on Windows
Feb 15, 2022
However, at first glance this looks like a variation on #26325 / #33419. Probably something else in the test is writing to the test's stdout or stderr, and because the extra output doesn't occur at a newline boundary, cmd/test2json isn't able to parse past it.
@bcmills afaict this particular test doesn't use stdout at all. I don't see anything in #26325 discussion that suggests how I could work around it. And why is it OS-specific? FWIW it's not just in the json, the backspace characters are encoded in plain text when not using -json.
FWIW it's not just in the json, the backspace characters are encoded in plain text when not using -json.
That's exactly what I'm saying. The testing package (and go test) does not inject those characters in the text itself, so they must be coming from some other package linked into the test binary.
You could try compiling the test and setting a debugger breakpoint to figure out what is writing those bytes. Perhaps they're coming from a subprocess (via os/exec) that has been set to forward its own stdout and/or stderr?