Allow outputting to /dev/stderr on Windows

[naalmlqpele]

Allow outputting to /dev/stderr on Windows

[benhoyt]

Interesting -- that Gawk port must have a special-case handling for /dev/stderr on Windows, because otherwise I'm not sure how that would work. I'm not sure I want to add special cases like this to GoAWK.

One idea I had for a workaround was using type (the Windows equivalent of cat) with "redirect stdout to stderr" operators, like this:

C:\> echo test | goawk "{print $0 > 'type 1>&2' }"

Would that work? (I don't have handy access to a Windows machine.)

[naalmlqpele]

Thank you, no, type commnand in windows is an cmd internal command that does not read from stdin. Even if it could work (more is a suitable command for this task), the structure of the command implies the creation of a separate process for each line being written, something that is a expensive task in windows.

Output to stderr is a usual operation in awk scripts. To use it in windows we need a way to reference this stream, if not by adding a special case handling for the /dev/stderr stream, maybe enabling an alternate way to reference the stderr stream.

[benhoyt]

the structure of the command implies the creation of a separate process for each line being written, something that is a expensive task in windows.

Yes, that's true if you did it using >. However, if you pipe it using |, a single process will be started and the command will stay running as it converts output from stdout to stderr. But yeah, that won't work if type does not read from stdin. You might be able to use findstr, or perhaps Get-Content if you're using Powershell.

But I'll keep this open to think further about adding /dev/stderr support on Windows.

[sergeevabc]

Dear @benhoyt, whatever you do, please refrain from following @golang lead in terms of cutting off Windows 7 users. It would be ridiculous if the well-known awk ports that have served us for decades continue to work, but your tool stops working.

[benhoyt]

Hi @sergeevabc, I'm afraid that ship has passed, as v1.25.0 is built with Go 1.21 (in general, I use the latest version to build, so I'm probably going to build the next version with Go 1.22). However, two things:

1. It's easy to download the source and build yourself with Go 1.20. Just git clone it and then type go build (with Go 1.20 installed).
2. I'm not opposed to a change to scripts/make_binaries.sh (which is what I use for building the release binaries) that builds 32- and 64-bit versions for Windows 7 as well. It should probably use go1.20.13 (the latest 1.20.x release) to do so. If you'd like that, please put up a PR.

Alternatively, you can keep using goawk v1.24.0, which is built with Go 1.20.6, so should work fine on Windows 7.

[sergeevabc]

@benhoyt, goawk 1.25 works fine on my end (Windows 7 x64), hmm. Apparently, I was misled about the compilation peculiarities after Golang's speech on dropping Windows 7 support. Anyway, please keep in mind there are dedicated users of that OS here and there is not a single feature in awk that requires a new OS. It is not for Microsoft or another American hegemon to decide what is outdated and what is not — a good hammer continues to hammer nails even when its manufacturer has ceased to exist. I can’t imagine that C developers would come up with such betrayal, geez.

[benhoyt]

@naalmlqpele Sorry for the delay. Does #225 work for you on Windows? It seems to work fine on Windows in CI, but I don't actually have a Windows machine handy to test it more thoroughly.

[naalmlqpele]

@benhoyt Trying to compile in windows to test it, but I get redeclared errors in several blocks. Is there any place from where to get the binary with the changes included to test?

[benhoyt]

Here's a GOOS=windows GOARCH=amd64 go build -ldflags="-w" build of this branch:

goawk-devstderr-windows-amd64.zip

[naalmlqpele]

@benhoyt , thank you for the build. Tested against multiple existing gnu awk scripts and several at hoc tests and working fine as expected without any problem. This includes outputs to stderr from print and printf, with and without ANSI escape sequences, with and without redirection to a file.

Any additional test you could think of, please, tell me.

[benhoyt]

No, that's good enough for me -- thanks! I've merged #225.

[sergeevabc]

1.26.0 works fine on Windows 7, 1.27.0 throws an error as follows

$ goawk127.exe

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

runtime.asmstdcall(0xc0)
        /home/ben/sdk/go1.22.2/src/runtime/sys_windows_amd64.s:75 +0x7a fp=0x22fc80 sp=0x22fc60 pc=0x47621a
rax     0x0
rbx     0x6e90d8
rcx     0x76f7c8
rdx     0x20
rdi     0x7fffffdd000
rsi     0x22fe78
rbp     0x22fdc0
rsp     0x22fc58
r8      0x0
r9      0x22fee8
r10     0x88a2e8
r11     0xc000004000
r12     0x22fec8
r13     0xc000004008
r14     0x6e8760
r15     0x0
rip     0x0
rflags  0x10293
cs      0x33
fs      0x53
gs      0x2b

[benhoyt]

@sergeevabc I build the released GoAWK binaries using the latest version of Go (Go 1.22 for GoAWK 1.27.0). The binaries are provided as a help to most folks, but it's easy to build yourself from source using Go 1.20 (which is the last version that fully officially supports Windows 7).

[sergeevabc]

@benhoyt There is a way to provide Windows 7 compatible builds via Github as @schollz did with his Croc.