You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hashibot opened this issue
Jun 13, 2017
· 4 comments
Labels
bugAddresses a defect in current functionality.providerPertains to the provider itself, rather than any interaction with AWS.upstreamAddresses functionality related to the cloud provider.windowsIssues and PRs that relate to using the provider on the Windows operating system.
Should have read credentials from %USERPROFILE%.aws\credentials, not %HOME%.aws\credentials, per these docs
Should successfully read from C:.aws\credentials
Actual Behavior
Attempted to read from %HOME%/.aws/credentials. Considering that HOME was set to C:, failed to read from C:.aws/credentials
Steps to Reproduce
Set an environment variable HOME to C: (or any drive)
Create a shared credential file with profile "myprofile" for an AWS account at %USERPROFILE%.aws\credentials
Run terraform plan
See the error
Copy that shared credential file to C:.aws\credentials
Run terraform plan
Still see the error
Set environment variable HOME to "C:"
Run terraform plan
See successful result
Delete environment variable HOME
Run terraform plan
See successful result (now using USERPROFILE because HOME is not set)
Important Factoids
I filed this PR to aws-sdk-go to (I think, I'm pretty new to go, but my local manual tests confirm it does catch "am I windows") vary environment variable by OS, not existence of one or the other. Again, new to GO, but as I understand this dependency, if that is merged to the master branch of aws-sdk-go, the next release of terraform will pick it up. If I am incorrect and there is still a change on the terraform side to consume that, let me know.
I did not fix the issue regarding if USERPROFILE (or HOME right now where HOME beats out USERPROFILE) is set to a drive without a "" that the ini file is not read correctly, as I don't really need to handle that case if I can get USERPROFILE read instead of HOME, but I figured I'd report it...
bflad
added
windows
Issues and PRs that relate to using the provider on the Windows operating system.
provider
Pertains to the provider itself, rather than any interaction with AWS.
labels
Jan 29, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bugAddresses a defect in current functionality.providerPertains to the provider itself, rather than any interaction with AWS.upstreamAddresses functionality related to the cloud provider.windowsIssues and PRs that relate to using the provider on the Windows operating system.
This issue was originally opened by @zmarois as hashicorp/terraform#14778. It was migrated here as part of the provider split. The original body of the issue is below.
Terraform Version
Terraform v0.9.5
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/zmarois/2edc76ea0a48551f65660e14c8edc0d9
Expected Behavior
Actual Behavior
Attempted to read from %HOME%/.aws/credentials. Considering that HOME was set to C:, failed to read from C:.aws/credentials
Steps to Reproduce
terraform plan
terraform plan
terraform plan
terraform plan
Important Factoids
I filed this PR to aws-sdk-go to (I think, I'm pretty new to go, but my local manual tests confirm it does catch "am I windows") vary environment variable by OS, not existence of one or the other. Again, new to GO, but as I understand this dependency, if that is merged to the master branch of aws-sdk-go, the next release of terraform will pick it up. If I am incorrect and there is still a change on the terraform side to consume that, let me know.
I did not fix the issue regarding if USERPROFILE (or HOME right now where HOME beats out USERPROFILE) is set to a drive without a "" that the ini file is not read correctly, as I don't really need to handle that case if I can get USERPROFILE read instead of HOME, but I figured I'd report it...
References
The text was updated successfully, but these errors were encountered: