Closed starbelly closed 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.
is the enotsup
error returned based on whether the old-style user
process or the new one? Or it happens regardless?
old-style? Like the old shell? It does for either new or old shell.
yeah that was the question. If it works for neither then it's not good.
Yea, neither.
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.
No, we should leave this as it is the only one that works fully.
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 returnok
per the platform (e.g., mac os, linux, *bsd, etc.). Until we can safely depend onio:getline/1
and/orio: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.