[Proposal] Add function `Mix.Shell.IO.password/1`

[Darragh Enright]

Hello folks 👋

I was making a tweak to Mix.Shell.IO.yes?/1 a while back and it occurred to me that it would also nice to have a password function, much the same as Mix.Shell.IO.prompt/1 except it would hide input from the user, which I am sure is familiar functionality to almost every developer.

I just had some time to look into how to implement this and it seems this would be easy to implement by wrapping :io.get_password/1 — for example:

def password(message) do

print_app()

:io.get_password(message <> " ")

end

Of course, in saying that, would that be a counterargument for precluding creating this functionality at all? :D

Thanks!
Darragh

[Darragh Enright]

For the sake of accuracy, I probably should correct the above code snippet to something like:

def password(message) do

print_app()
IO.puts(message <> " ")

List.to_string(:io.get_password())

end

[José Valim]

Unfortunately :io.get_password works only in limited scenarios, so I don't think we should provide first class conveniences around it until this limitation is addressed in Erlang/OTP:

$ elixir -e "IO.inspect :io.get_password"
{:error, {:request, {:get_password, :unicode}}}

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/16a21fa4-0984-445a-be62-581bfce0f32cn%40googlegroups.com.

[Darragh Enright]

Hi José

No worries! Thanks for the feedback :)

I didn't completely understand the limitations, but googling here suggests that it doesn't work from escript (and the conversation also points out that it's not even documented, something I didn't realise). So I guess that's the reason/limitation? Not sure if there are others.

http://erlang.org/pipermail/erlang-questions/2011-November/062802.html

Is there an argument for looking at ways to implement this functionality in a different way, or would you prefer to wait for upstream changes that address the limitation in OTP and wrap the functionality then, assuming that there are plans to address the limitations?

Thanks again!

Darragh

[Eric Meadows-Jönsson]

> Is there an argument for looking at ways to implement this functionality in a different way, or would you prefer to wait for upstream changes that address the limitation in OTP and wrap the functionality then, assuming that there are plans to address the limitations?

There is no good way of implementing it in Elixir standard library so I would suggest looking into improving things upstream.