Also write out an .env.sh file which can be safely be 'source'd into a shell.

[richardpark-msft]

No description provided.

[richardpark-msft]

CC: @LarryOsterman

[github-actions]

Hi @richardpark-msft. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[richardpark-msft]

I just need to test this.

[github-actions]

Hi @richardpark-msft. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[github-actions]

Hi @richardpark-msft. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing /reopen if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the no-recent-activity label; otherwise, this is likely to be closed again with the next cleanup pass.

[weshaggard]

@richardpark-msft is this still interesting? Is there no way to avoid writing these secrets to disk?

[richardpark-msft]

@richardpark-msft is this still interesting? Is there no way to avoid writing these secrets to disk?

They weren't necessarily secrets (for instance, one of the env variables is the endpoint you connect to, without any keys). However, the original reason the .env file wasn't source-able was because of connection strings, which have embedded '='s in them. Given our push away from those cred types, I think we can just drop this PR altogether!