Perhaps instead of exists filename you could write grep '.' filename.

Perhaps instead of exists filename you could write grep '.' filename.

Yea, maybe, or I could write my own exists command (which currently do not allow me to use the negate keyword), but the thing is:

• exists already have some extra check flags in there (-readonly, -exec).
• an empty file would, in my head, in most situations be a red flag I would want a test to shout about.

Would you like to send a patch for this?

cc @bcmills @mvdan

@thanm I may when I find time, but my first attempt running the tests inside cmd/go was a big failure, so I need to look into that first.

I agree with @ianlancetaylor: you can use grep for this. ! grep . stdout is a common way to test that a command didn't print to stdout, for example. And the exists command isn't called notempty, after all.

That would mean doing this for every file:

# Check that it exists an is executable
check -exec filename
# Check that it's not empty (which I assume means reading the entire file)
grep . filename
# ... next file

And the exists command isn't called notempty, after all.

Well, it's not called readonly, either.

This is not a big deal for me, but I would suggest a lower barrier for proposals for non-breaking changes in internal test APIs. If, by adding these 2 lines, you discover a fatal bug in File.Sync() on some platform, it would be well worth it.

What I mean is that the default shouldn't change to check for non-empty files. The "readonly" check is opt-in via a flag, for example. Maybe -notempty?

I've been taking some steps to properly extract the cmd/go script engine (https://go.dev/cl/419875) in order to reuse it for #27494. The approach I've been taking allows the registration of arbitrary commands, and also allows the internal commands to be extended by replacing their implementation.

With that approach, you could modify your own script's exists command to support whatever extra options you want. 🙂

At any rate, I don't think we should make this change in cmd/go itself until / unless we need to use it in a cmd/go test. (The script engine is intentionally internal to cmd/go for the time being. Perhaps at some point we can file a proposal to move it to x/tools or x/exp or someplace like that.)