Fix 'go generate ./...' on windows

[part22]

When running the go generate ./... command, pkg\cheatsheet\generate.go panics because the embedded translation files cannot be found. Previously mentionned here.

This is caused by the method filepath.Join, which uses the OS-specific path separator.

Join joins any number of path elements into a single path, separating them with an OS-specific Separator.

See filepath.Join documentation.

On Windows, it is \ (backslash). However, embed.FS.ReadFile expects the path separator to be / (slash) regardless of the OS.

The path separator is a forward slash, even on Windows systems.

See embed documentation.

To fulfill the contract of embed.FS.ReadFile, the path.Join method should be used instead since it always uses slashes as the path separator.

Join joins any number of path elements into a single path, separating them with slashes.

See path.Join documentation.

I have tried running go generate ./... on Ubuntu using WSL and the functionality seems unchanged.

Note I also ran in another problem coming from pkg\jsonschema\generate.go where it panics because the string it is looking for terminates by \n.

DocumentationCommentStart    = "<!-- START CONFIG YAML: AUTOMATICALLY GENERATED with `go generate ./..., DO NOT UPDATE MANUALLY -->\n"

However on Windows the new line characters are \r\n. The solution was to disable git autocrlf (git config core.autocrlf false) and to renomalize the files (git add --renormalize .) to have the new line character match the one in DocumentationCommentStart. It might be worth including something in the doc about how to run go generate ./....

• Please check if the PR fulfills these requirements

• [ ] Cheatsheets are up-to-date (run go generate ./...)

• [ ] Code has been formatted (see here)

• [ ] Tests have been added/updated (see here for the integration test guide)

• [ ] Text is internationalised (see here)

• [ ] Docs have been updated if necessary

• [x] You've read through your own file changes for silly mistakes etc

[stefanhaller]

Thanks, but this is already fixed by #3705 and #3706 (which I told you about here :wink:).

[part22]

Haha, yeah, I saw it too late. I'll close the PR.