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
That special case was added in https://go.dev/cl/37960, with the explanation “return a dummy user instead of failing”. However, it did not explain why failing is not the correct behavior in that configuration, as I would expect it to be — it seems like the code was changed to conform to an erroneous test, instead of changing the test to conform to the previously-correct(?) code.
The explanation given was that “The UserHomeDir test succeeds on the builder, but not when run
manually where HOME is set to the host $HOME.”
To me, that seems like a bug in the exec wrapper, not os.UserHomeDir — and, indeed, later (in https://go.dev/cl/167938) the wrapper was changed to avoid propagating $HOME to the device.
A month after the two special cases were added, the signature of UserHomeDir was changed to include an error return value (#28562). It seems to me that the special cases should have been removed at that point, but they weren't, and I think that was an oversight.
I propose that we add a GODEBUG guard for those special cases (mostly for a smoother version-based transition per #56986) and default UserHomeDir and os/user.Current on android and ios to be consistent with linux and darwin respectively as of the next Go version.
(CC @golang/android @golang/ios)
The text was updated successfully, but these errors were encountered:
This proposal was motivated by https://go.dev/cl/520262 (for #57638), in which it is turning out to be more difficult than it ought to be to add tests for UserCacheDir and UserConfigDir because of lingering bugs on android and possibly ios.
android was special-cased to return / in https://go.dev/cl/139717.
The commit message and code-review comments do not explain why, as far as I can tell, and no code comment was added explaining it either.
I'll note that code review comments did include the unanswered question "Or would /data/local/tmp be better?", which adds a little context on how "/" was chosen.