README suggests piping to file, but file receives just "Config for pennsylvania-production written to .env"

[cforcey]

Thanks so much for this great extension. We find it helps us quickly output our heroku config variables.

Returning to the command after a little time, we glanced at the README, skipped over the --env=production.env advice, and picked out the piping syntax for quickly creating a file out of our production .env file.

Pipe keys to STDOUT

$ heroku config:pull > config/production.env

While at one point this might have worked, the output of the command is now the human readable sentence "Config for pennsylvania-production written to .env" which I am sure no one truly wanted when piping, expecting instead something useful as production.env.

In my tragi-comic case, I saw that the file contained just one line, assumed it failed (without reading it and realizing that my .env file had been overwritten), and later ran tests that wiped our production database at DATABASE_URL.

All of that was my fault -- when the pipe did not produce what was expected, I should have read what was in it and confirmed that my .env was not overwritten. I should have also known that heroku DATABASE_URL settings override everything else you set for the your local environments, making a pull from a rails app especially dangerous.

That said, I think the piping lines on the read me should be removed or the output changed to something that can be piped normally. Let me know what you think! It is probably beyond the scope of the gem to warn other numbskulls like me about DATABASE_URL and other potentially catastrophic environmental variables being set in .env, but if you have heard of this before it might be worth considering.

Happy to submit a PR with verbiage once an approach is picked. Thanks again for the great plugin and all the work you put into it.

[cforcey]

After running heroku plugins:update, the behavior is now as expected. Piping to a file renders the variables and not the human readable message to the file. This should be marked closed. The only remaining idea is a warning about DATABASE_URL, but that is beyond the scope most likely of a simple README and common sense to most. Thanks and sorry for the false alarm.

[ddollar]

You should almost never use --overwrite when pushing. If you do, you should consider adding --interactive. I would accept a pull request to make interactive mode the default when overwrite is on.

[ddollar]

Ah I think I see what you mean. Yeah you should be careful when pulling production variables down to development but the list of those is going to be huge (REDIS_URL, MONGO_URL, all sorts of things) that I don't think there's any blanket approach we can take to warn about them.

[cforcey]

Thanks for the quick response. Yes, this was an attempt to pull into a file, but the older version piped just the message for success and writes into the .env file rather than the specified file on the pipe. This PR fixed that all up by piping the variables as expected in that case: https://github.com/ddollar/heroku-config/pull/22/files. I agree that no amount of warnings on the README could cover all the things you might pull down from a production .env. Thanks for your work on this cool extension.