starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 01:15:51 +03:00

[GH-ISSUE #998] Enhancement: Accept - (single hyphen) as a filename meaning "stdin" #585

New issue

Open

opened 2026-03-01 21:44:44 +03:00 by kerem · 6 comments

kerem commented

2026-03-01 21:44:44 +03:00

Owner

Originally created by @rmunn on GitHub (Feb 14, 2022).
Original GitHub issue: https://github.com/nektos/act/issues/998

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.

Originally created by @rmunn on GitHub (Feb 14, 2022). Original GitHub issue: https://github.com/nektos/act/issues/998 ## 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: ```bash 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: ```bash 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.

kerem added the

kind/feature-request

label

2026-03-01 21:44:44 +03:00

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@rmunn commented on GitHub (Feb 14, 2022):

This is #907, opened in a new issue because I can't re-open issues that the stale-bot closed.

@rmunn commented on GitHub (Feb 14, 2022): This is #907, opened in a new issue because I can't re-open issues that the stale-bot closed.

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@catthehacker commented on GitHub (Feb 14, 2022):

Multiple flags can't receive input from stdin and it will be confusing to implement it only for a single flag.

@catthehacker commented on GitHub (Feb 14, 2022): Multiple flags can't receive input from stdin and it will be confusing to implement it only for a single flag.

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@rmunn commented on GitHub (Feb 16, 2022):

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.

@rmunn commented on GitHub (Feb 16, 2022): 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](https://curl.se/docs/manpage.html) 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](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html)! (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.

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@rmunn commented on GitHub (Mar 7, 2022):

Contentless comment to prevent stale-bot from thinking this is stale.

@rmunn commented on GitHub (Mar 7, 2022): Contentless comment to prevent stale-bot from thinking this is stale.

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@airtonix commented on GitHub (Jul 18, 2024):

instead of making a flag mean two things, have separate flags for distinct meaning:

--eventpath ./path-to-event.json
--eventpath-stdin
--upload-file ./path-to-file-to-upload
--upload-file-stdin
etc

now you can exit 1 when more than one of the --*-stdin flags is used.

@airtonix commented on GitHub (Jul 18, 2024): instead of making a flag mean two things, have separate flags for distinct meaning: ``` --eventpath ./path-to-event.json --eventpath-stdin --upload-file ./path-to-file-to-upload --upload-file-stdin etc ``` now you can `exit 1` when more than one of the `--*-stdin` flags is used.

kerem commented

2026-03-01 21:44:45 +03:00

Author

Owner

@rmunn commented on GitHub (Jul 20, 2024):

How is that better than the standard - filename meaning stdin/stdout? Adding a bunch of new flags just increases the length of the help text required, whereas - is a long-standing preexisting standard, whose absence violates the principle of least surprise.

@rmunn commented on GitHub (Jul 20, 2024): How is that better than the standard `-` filename meaning stdin/stdout? Adding a bunch of new flags just increases the length of the help text required, whereas `-` is a long-standing preexisting standard, whose absence violates the principle of least surprise.

kerem referenced this issue

2026-03-01 21:51:29 +03:00

[PR #585] [MERGED] add codecov integration #1508

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#585

No description provided.

Rows
Columns