Use cat instead of printf

[Jamesking56]

Fixes #3

[Jamesking56]

@ericof Is this project still maintained?

[ericof]

@Jamesking56 — yes, actively maintained again, and apologies for the long silence on your question.

#22 landed today: a bats test suite plus shellcheck in CI, and fixes for three of the open deploy bugs. Which brings me to your patch.

Your diagnosis was right, and half of this is already shipped. Reading the file line by line instead of pushing it through an unquoted $(...) is exactly the fix — the word-splitting was also the cause of #21 (env_file values containing spaces getting truncated to their first word). That is now the implementation in main, so the loop half of your diff has effectively landed.

Two reasons I can't merge it as it stands:

1. printf '%s' "$ENV_FILE" → cat "$ENV_FILE" is a breaking change. The env_file input currently takes the variable content, not a path. Switching to cat means every existing caller passing content would break, since cat would try to open that content as a filename. That is really the substance of env_file option doesn't work #3 and it needs to be additive rather than a swap.

2. The quote stripping (sed -E 's/^"(.*)"$/\1/') goes the opposite way to what Fix deploy hangs and env_file word-splitting, on a new test harness #22 settled on. Values are now taken verbatim to match docker --env-file, where quotes are part of the value rather than delimiters around it. There is a test asserting that: "env_file keeps quotes in a value verbatim (issue env_file values containing spaces are word-split and break the deploy #21)".

What happens to #3: the capability you wanted is coming as a separate env_file_path input — a path read from the workspace, with env_file keeping its current meaning so nobody's workflow breaks. That keeps #3 open until it lands.

If you would like to write that one, it would be very welcome and I'll review it promptly this time. Otherwise I'll pick it up shortly.

Closing this PR — with thanks, it did point at a real bug.