Open jonsequitur opened 6 years ago
@jonsequitur would you imagine it looking something like this? https://github.com/hartmannr76/command-line-api/commit/17f0f18479dadd36cb7310d56b8d7588c0006469
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)
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
.
This would be nice so that I don't have to mix calls to
IConsole.Out.WriteLine
andConsole.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.