nektos
Enhancement: Accept - (single hyphen) as a filename meaning "stdin"
Describe feature
By Unix convention, if a tool accepts a filename as input, the filename - (a single hyphen) will be interpreted as "read from stdin" so that the tool can be used in a pipe. I just tried to do that with act, and it thought that I was trying to read a file named - in the current directory.
Use case: I want to be able to create a template of an event file, then do something like this:
cat event-template.json | sed -e "s/SHA_GOES_HERE/$(git rev-parse HEAD)/" | act --eventpath -
But because act doesn't use the "- means stdin" convention, I have to create and clean up a temporary file instead:
fname=$(mktemp)
cat event-template.json | sed -e "s/SHA_GOES_HERE/$(git rev-parse HEAD)/" > "$fname"
act --eventpath "$fname"
rm "$fname"
That's easy enough, but it's a little bit of added complexity that wouldn't be needed if I could say --eventpath - and have act read the event from stdin.
Note that there are other options, like --secret-file and --env-file, that could also benefit from the "- means stdin" convention. --eventpath shouldn't be different from other options that take filenames: either all of them should accept - for stdin or none of them should.
This is #907, opened in a new issue because I can't re-open issues that the stale-bot closed.
Multiple flags can't receive input from stdin and it will be confusing to implement it only for a single flag.
Yes, in a situation where you'd be specifying multiple files as parameters to flags, like --eventpath evt.json --secret-file secrets.env --env-file myenv.env, only one of those could be replaced by - in any given invocation. But that doesn't mean that it doesn't make sense to implement the option for them. Because some use cases will be best solved by passing stdin to the eventpath (like I wanted to do), while others will be best solved by passing stdin to a different flag, like --env-file.
There are lots and lots of Unix tools that use - to mean stdin, and many (though not all) of them allow it in many different flags. For example, look at the manpage for the curl command and search it for the text stdin. The following curl flags allow specifying - as stdin:
- -K / --config
- -b / --cookie
- -d / --data
- -F / --form
- -H / --header
- --json
- --proxy-header
- -T / --upload-file
Obviously, you can only pass stdin to one of those flags at once. But if "multiple flags can't receive input from stdin in the same command" was a good reason not to implement the feature, then curl wouldn't have done it this way.
Rather, what makes sense (and what most Unix utilities implement) is that anywhere a flag expects a filename, - means stdin or stdout, depending on context. (E.g., --output-file - means to write to stdout, not stdin, which is obvious from context). It's even in the POSIX standard! (Scroll down to Guideline 13).
I do agree, though, that it would be confusing to implement this for only a single flag. It should be implemented for all flags that take a filename. That way, whatever the use case that might want to pass values into stdin (say, passing a set of environment variables through sed such as cat dev.env | sed -e 's/development/production/' | act --eventpath simulated-deployment.json --env-file -), that use case will be possible, and flags won't have confusing and contradictory meanings.