Add option to read from stdin

[cgmb]

Support for writing to stdout was requested in #25 so guardonce could be integrated with other tools. I considered adding support for reading from stdin to go along with that, but eventually decided against it due to time constraints. It's still a good idea, though, so it's going in the backlog.

One trick to this is that reading from stdin implies writing to stdout, because where else would we put the output? I was thinking I'd name the flag --stdio to make that fact really obvious, but --stdin seems to be the less surprising name. So, I'll probably just name the flag --stdin.

Another consideration is the path. The input file path is often used for generating the include guard pattern, but guardonce doesn't know the actual file path if input comes from stdin. There needs to be a way to explicitly pass guardonce that information, so we'll add an --assume-filepath=<file> option to do so.

--assume-filepath will be required when using --stdin together with --pattern for guard2once or checkguard and will be required even when using --stdin alone for once2guard. The difference here is because once2guard always uses a pattern—if you don't specify one, it just uses a default pattern.

[fredRos]

The --assume-filepath=<file> option is handy in another situation that I encountered. With the bazel build tool, a unit test copies all inputs to a sandbox directory and never touches the original source such that the file path is not where the source "usually is" inside the source tree.

With the added option, I could just specify the original path to be used for the include guard, where ever the file to edit is

[cgmb]

Interesting. Thanks for the insight. I'm curious to know more about the context for that. Which guardonce tool do you use with the sandboxed files and why?

I'm not sure when I can get to this task, but I will keep your use case in mind when I do.

[fredRos]

I created a script to create include guards according to our company style guide. I use guard2once to have a well defined input, and once2guard in the 2nd step because headers can either have a #pragma once or some include guard. In order to test that it works, I have to run it on actual files. Usually the script would be invoked on a file under version control somewhere in the source tree, and the guard depends on the relative position. The unit test files are not in the usual places, so to check that the right guard is produced, I have to fiddle with relative paths. It can be done but --assume-filepath=<file> would simplify the process