Rule checker's CLI usability

[fabxc]

• $ rule_checker -h shows flags intended for Prometheus that were defined in imported packages. An explicit flag set for the rule checker should fix that.
• The obvious input is a file - so having a -rule-file="" flag is inconvenient (and documented wrongly as -ruleFile on the website) . It should simply use the first non-flag argument, i.e. $ rule_checker my/fancy.rules (with -rule-file="" for backwards-compatibility).
• The file argument should be a glob.
• (The rule checker prints standard-formatted output (just that there hasn't been a never-ending discussion what the correct standard-format is, yet), which is close to what #21 asks for. It would just need a -w flag that overwrites the input file. Comments have to be preserved for that, however.)

[matthiasr]

I don't think it should glob in the tool – it should just consume all non-option arguments as input filenames (and stdin if there are none). This matches standard unix tool behaviour and combines best with shell globbing or other tools.

A second level of glob expansion would make it practically impossible to pass in filenames that contain special characters, and open a lot of avenues for things to go wrong. In interactive invocation, globbing is the shell's job.

[fabxc]

You are right - wasn't thinking there, thanks.

[juliusv]

👍 And if no files are specified, it should read from stdin, like any other self-respecting Unix tool.

[fabxc]

Great.
Overwriting probably needs some discussion on what the one-and-only correct syntax is.

I could do the rest now.
Currently the rule checker panics on everything - thus, it exits with 255, which is also documented. Can we break backwards-compatibility here? I would rather go for 2 for non-existent files/directories (consistent with flag package) and 1 for actual processing errors.

I doubt there is anyone checking for anything other than non-zero.

[juliusv]

@fabxc We have no idea if anyone is doing that, but as long as it's in the CHANGELOG.md for the next release and we're in version 0.x, it's totally fine to change.

Regarding #21 I think that's very low priority for now. It'll be a nice thing to have long-term though.

[juliusv]

This can be closed now, right?

[fabxc]

Yes, the remains are covered by the old ticket.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.