Skip to content
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

add support for Console.In to IConsole #275

Open
jonsequitur opened this issue Nov 2, 2018 · 3 comments
Open

add support for Console.In to IConsole #275

jonsequitur opened this issue Nov 2, 2018 · 3 comments
Assignees
Labels
Area-API needs discussion Further discussion required

Comments

@jonsequitur
Copy link
Contributor

No description provided.

@jnm2
Copy link

jnm2 commented Mar 4, 2019

This would be nice so that I don't have to mix calls to IConsole.Out.WriteLine and Console.ReadLine.

Would you consider IConsole.In.ReadPassword()?

I have an implementation that (when interactive) sniffs the console's current font to see if it has characters for the Windows password char (\u25CF, works with Consolas), falling back to '\u2022', \a (works on Terminal which used to be the default Windows console font), or *, in that order. Then it sets and replaces the console encoding if necessary. Probably the best thing would be to make this pay-for-play and have the user specify which character to use.

Then, it shows this character as the user edits. When the user presses enter, the displayed password length changes to ten.

If stdin is redirected, it just echoes ten dots after the line is read.

@hartmannr76
Copy link

@jonsequitur would you imagine it looking something like this? hartmannr76@17f0f18

This is my first time tinkering in these repo's so I just want to make sure the interface and added methods look 🆗 before I start adding tests to work with it.

This functionality would be helpful to read in additional arguments passed in via the cli (which is why I wanted to tackle this)

@jonsequitur
Copy link
Contributor Author

Thanks, @hartmannr76. ReadLine and ReadToEnd seem like extension methods to me. They'll be useful and people will expect them, so it's good to include them, but perhaps not on the interface itself. One of the motivations for defining these IStandardStream interfaces was to restrict the surface area a bit from the existing TextReader and TextWriter types, especially with regard to overloads taking various non-string types, so that this kind of thing will work: https://github.com/dotnet/command-line-api/blob/master/src/System.CommandLine.Rendering.Tests/Example_TOP.cs#L75

So what is a good common case between these methods?

There's probably also a discussion to be had about whether these should use PipeReader and PipeWriter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-API needs discussion Further discussion required
Projects
None yet
Development

No branches or pull requests

3 participants