-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing might be too strict #1
Comments
Maybe @geemus knows something about this. |
Not sure off hand I'm afraid. kr did the implementation work there (I just did a couple tweaks and was told to maintain). It certainly does appear invalid and is surprising that it wouldn't blow up more spectacularly even in the ruby netrc thing. |
For some reason @mfine had a similarly messed up .netrc file. I'm thinking this project might need to be just ignore stuff it can't parse (or at least offer that option). |
It is a mixed bag. Ignoring un-parseable stuff is great as long as that isn't the pair you are trying to look up (in which case having it tell you it doesn't exist is confusing in it's own right). Not sure if fail fast is better or fail accurate, so to speak. May depend on how widespread these issues come to be. |
I've run in to this issue with Heroku and Terraform. Using the Heroku cli to login to an SSO endpoint creates
Any time I use a go application that uses this library I get |
Hello all! I'm a member of the Terraform team, and we just saw a new issue hashicorp/terraform#18610 that seems to be covering the same problem as reported by @billmoritz above. My thought to address this would be for the parser to attempt graceful recovery when it encounters something it can't parse. Specifically, when encountering an invalid token, it could discard the entry it's currently parsing and then seek forward to the next line that starts with the I agree with the above discussion that it's not ideal for an error to just be silently ignored, and I have a possible compromise for that too: although the existing Does that seem like a reasonable path forward? |
@deafbybeheading had the following messed up .netrc file:
Where each use of REDACTED was a password. Somehow geemus/netrc was able to read hid creds from this file, but go-netrc wasn't.
I'm actually not sure that we should handle this. If the .netrc is clearly invalid, you should have to fix it. The netrc manpage certainly makes me think it's invalid.
The text was updated successfully, but these errors were encountered: