erlef / rebar3_hex

Rebar3 Hex library
Apache License 2.0
101 stars 49 forks source link

Use the win32 method for getting passwords on all platforms #130

Closed starbelly closed 5 years ago

starbelly commented 5 years ago

In light of io problems that should be dealt with in Erlang/OTP in regards to echoless prompts we should switch to the same method of prompting for passwords that we use on win32 ala mix/hex.

Specifically, we are seeing issues where by io:setops/1 now consistently returns {error, notsup} where it should return ok per the platform (e.g., mac os, linux, *bsd, etc.). Until we can safely depend on io:getline/1 and/or io:get_password/1 we should resort to what appears to be the only reliable method for getting a password. That is reading and clearing the input at a prompt every 1ms.

tsloughter commented 5 years ago

I'll just note that we also saw issues with the port_command version of the password prompt that it uses when io:setopts/1 returns an error. This would successfully get the password with a blank prompt but it would cause any prompt in the program after that to not accept input.

So in the case of the cut command after getting the local password to decode the write key it asks if you want to push the new tag to the remote git repo and would appear to hang when you try to input anything.

ferd commented 5 years ago

is the enotsup error returned based on whether the old-style user process or the new one? Or it happens regardless?

tsloughter commented 5 years ago

old-style? Like the old shell? It does for either new or old shell.

ferd commented 5 years ago

yeah that was the question. If it works for neither then it's not good.

tsloughter commented 5 years ago

Yea, neither.

starbelly commented 5 years ago

Realized what changed. This bug had laid dormant. Prior to 7f72a34e4959dfab3cb299910bd06c266203c200 the order of prompts in rebar3_hex_cut didn't allow for this bug to be experienced. Specifically, asking for the password was the final prompt.

With that in mind, do we want to restore the old order of prompts for this command and revert this patch? Might be counter-productive for moving forward.

tsloughter commented 5 years ago

No, we should leave this as it is the only one that works fully.