-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Read-Host : Add Trim Option #19680
Comments
I agree that this would be helpful, but just to note the workaround: |
Yup, that workaround does the trick. But as with all workarounds, of course, it's not part of the official documentation and many people won't think of it.
…___________________________
The Cyber Hymnal™ <><
http://www.hymntime.com/tch
|
@rhubarb-geek-nz, from that perspective nothing that can be implemented in PowerShell code - no matter how cumbersome and non-obvious - constitutes a workaround. The point here is that wanting to trim user input is the typical use case, yet:
|
Very much this. see #16660 (comment) for why I think the vast majority of the time
I think that about 99% of the time Read-Host is used because the author is writing like 1970s basic and asking the user to type things in when they should, in fact, be asking for parameters. e.g.
not
How often in practice does the user type spaces which should not form part of the input? we're probably more concerned that user doesn't give empty input
but no one is asking for an option for that, nor to ensure that input is numeric nor split comma separated input into multiple items or any of the many other things which might be bolted on Adding We might well say |
This is completely unrelated to what you're talking about (parameters for technical users familiar with PowerShell), and this conflation - especially if used to argue against The argument re not providing a switch for something that can also be done manually, after the fact, is specious: Why have |
@mklement0 I wonder if you are just playing devil's advocate, There are a few cases where we display a menu or ask the user for a selection, or pause until the user hits enter which need Where the dividing line lies between "use two cmdlets" like |
This is a completely separate debate - bringing it up here is inappropriate and only causes confusion. |
I only know for sure with FAT, but I think it is true of all file systems, the directory keeps the files in creation order. I think .NET (and possibly the windows API) sorts before returning. But I don't think the API has a "Ask the file system for 10 files in this directory", we get all the files and if we only want 10 the work has been done.
Yes that is generally true. But if I can call a rest api which returns 1,000,000 items and apply a where on the client side, or I can call the API with the where condition and return 1 item. It's plainly better not to bring the other 999,999 over the wire and send them down the pipeline. If I have a function which calls an API which usually returns about 100 items I'll probably sort by name rather than tell users to do it, because 9 times out of 10 they want that order, and for the 10th the cost of the extra sort doesn't matter.
Actually there is a mechanism and Select-Object uses it. try AIUI it raises a special terminating error, which is not available to other things. If it is a the SQL query or rest API that gets a ton of stuff, it only stops that going down the pipeline but for something like
Not over-complicating is good :-) If you think of
If anyone wants to know why I'm not taking this to the cmdlet working group, and why if another member does I'd argue it's not even something we should accept a community PR on, then I've laid out why. Sorry for confusing you. |
Glad to hear it. I encourage you and @rhubarb-geek-nz to hide all your comments here as "Off Topic." (I'm happy to hide my responses thereafter.) |
The 'workaround' is part of the official documentation; PS> help Read-Host And System.String.Trim. The new option may do a disservice to the very audience you are trying to help. If people think they are writing pure, portable PowerShell script may find either
or
If they run their script on a previous version of PowerShell. So they now need to be aware that their script will only run on PowerShell 7.4.0 If they publish their script in So unless Publish-Module parses the scripts for unsupported parameters you may end up with published modules, while tested and working with one version fail on previous versions of PowerShell Core or on WindowsPowerShell. |
@rhubarb-geek-nz, since the off-topic ship has sailed, allow me to summarize your arguments - I do hope I got the gist right:
|
Not quite
|
|
If I see additional people who are confused I'll be sure to do that.
While true, this does not really help matters.
As the only person from the cmdlets wg who has given this any time I haven't seen anything to persuade me - after an extensive discussion - that it is worth discussing in the wg. @aksarben can we close this now ? |
Given how this thread has unfolded, I'm sure those who stumble upon this will be - you may simply never hear from them.
It is inappropriate to speculate about the intent of other workgroup members (without having received actual feedback).
That - unlike many other comments in this thread - is an on-topic argument; it has been addressed before, but let me try to clarify:
|
Me! Me! I am. The comparison with param was made and how it will translate to given type and also provide autocompletion. It would be really useful for interactive applications to have the same capability, eg at a top level menu to use Read-Host to return an enum value of the valid options, likewise with numbers only accept numerical input, ideally with ranges, or values from a ValidateSet. |
@rhubarb-geek-nz, yes, there is a lot of room for improvement, but what you're suggesting is (commendably) not arbitrary:
At least some of this functionality could be provided if A fundamental question is how sophisticated the currently bare-bones |
There is nothing stopping you from replacing function Read-Host {
[CmdletBinding(
DefaultParameterSetName = 'AsString',
HelpUri = 'https://go.microsoft.com/fwlink/?LinkID=2096610'
)]
param(
[Parameter(Position = 0, ValueFromRemainingArguments = $true)]
[AllowNull()]
[System.Object]
${Prompt},
[Parameter(ParameterSetName = 'AsSecureString')]
[switch]
${AsSecureString},
[Parameter(ParameterSetName = 'AsString')]
[switch]
${MaskInput},
[Parameter(ParameterSetName = 'AsString')]
[switch]
${Trim}
)
begin {
$withTrim = $PSBoundParameters.Remove('Trim')
$scriptCmd = { Microsoft.PowerShell.Utility\Read-Host @PSBoundParameters }
$steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
$steppablePipeline.Begin($true)
}
process {
if($withTrim) {
return ([string] $steppablePipeline.Process()).Trim()
}
$steppablePipeline.Process()
}
end {
$steppablePipeline.End()
}
clean {
if ($null -ne $steppablePipeline) {
$steppablePipeline.Clean()
}
}
} |
Thanks for the code, @santisq - I encourage you to publish it as a self-answered question on Stack Overflow to give it wider exposure, along with a link to this issue: that may draw more users who'd be interested in seeing this implemented as part of Anyone who'd put such a proxy function in their
Given how trivial this would be to implement, I think that's a false dichotomy - there is no either-or here. Again, the only question should be: is this a worthwhile addition to Whether a given feature is worthwhile is - at least initially, pending a potential appeal, as codified here - is to be decided by the relevant working group (and how much time passes before that happens is also a reflection of priorities, I suppose). It certainly shouldn't be decided unilaterally by a single member of a working group, especially in an underhanded manner (removal of the "Needs-Triage" tag, withholding of the relevant "WG-*" tag, badgering the OP to close their issue). |
@mklement0 leave the ad-hominems out. You might also want to rethink whether the definition of badger "repeatedly ask (someone) to do something; pester:", fits with a single "Is it ok if" question.
|
Just a small point. I have always taught that All user input is dangerous and evil until you prove otherwise (and even then...).. I have not seen a huge demand for this kind of feature either. I may be looking in the wrong place! ;-) I learned long ago that there is no such thing as "trivial to implement". And the implantation is not the only cost involved. Anything that unnecessarily adds to the PowerShell package is to be avoided. I am not convinced of the need for such a switch. I will add this issue to the Cmdlet WG's agenda, although I can't promise how quickly we can get to it. |
Thank you. (I won't defend the merits of this proposal further - I think all angles have been covered.) |
@mklement0 thanks for the reminder - I have labeled this issue accordingly. |
There was no ad hominem. It was an accurate description of your actions - save for "badgering" being too strong, given the lack of repeated action; does "urging" work?
It is inappropriate to bypass the official procedures the way you did and seem to be defending now.
While I wouldn't characterize your conduct here as "trolling", "disruptive" seems apt. More importantly, that your unilateral actions were inappropriate is implied by the following statement from the Working Groups definition:
|
@mklement0 I'm going to disengage from your comments , as it appears others have had the wisdom to do before me. The post no longer need triaging. I removed that label. I did not close it because (a) the OP might want to keep it open, (b) other members of the WG might have a different view to mine as @doctordns has now shown. It is very clear from everything I have said where my opinion as a one member of that WG, ends and where other members need to speak for themselves. But my opinion (which will now go to WG) is as in the 5 points above. I will also have a word with the powers that be about the definition of trolling and possible ways forward. |
@PowerShell/wg-powershell-cmdlets reviewed this proposal and rejects the proposed addition to |
@SteveL-MSFT , re documentation:
|
I assume you've come across my complaint about inappropriate unilateral behavior in this thread, summarized here, so there's need for me to report it separately anymore.
I think said behavior is at odds with the mandates of working-group members, as already implied by the existing documents describing the WG duties. However, one additional inappropriate behavior that unfolded in the wake of this thread strikes me as worth adding as a DO NOT to Working Groups (WGs):
To address said comment:
|
Thanks for your consideration…
…___________________________
The Cyber Hymnal™ <><
http://www.hymntime.com/tch
|
@mklement0 - I previously blocked you, but github does not implement block as I thought so I have removed it and you should see this mention. The cmdlets working group met yesterday and this occupied some of the meeting. In due course you will see something on how to complain if something is done in the name of a group, whether that is one person saying "As a member of the group I think..." or "The working group feels..." (i.e. a quorum has discussed it and concluded and I am reporting back on their behalf). My take away from that was that everyone is aware of the need not to muddy the waters between those two (although I should say "as one member of the WG I think that, the rest of the WG haven't mandated me to say so"). There is a general presumption that working groups should see all issues which relate to their area. However there is a very large backlog and for many groups this is growing . Any "committee" takes longer to work through issues as it gets bigger and the only way for WGs to process more is with more time from their current set of unpaid volunteers. So despite what we would all wish, the practicalities mean working groups can't see all issues. One of the tasks of group members is selecting which ones are seen. It is valid for someone to say "As a member of A working group, this isn't something I'd pursue but experience tells me X might feel differently so let's see if X has a comment" or to say "As a member of A working group, this isn't something I'd pursue. I believe my fellow members of A would feel the same if asked, so I will not be trying to get it on the WG's agenda". Which leaves the door open for someone else on the wg to say "Actually James I think we should talk it through". Because of a procedural hiccup I have been on the WG for a longer time than I have had the github authorization to change tags and close issues. It did not feel right to me to close this issue, since I wasn't going to put in front of the cmdlet group I didn't tag it as belonging to that group, and I thought it had been sufficiently triaged so I removed that tag. In hindsight my understanding of how things should be tagged may have let me down. This could have been tagged as "falls under the auspices of this wg", while knowing it is in a large pile of things which won't even be considered. Hopefully your other issue on the triage tag will come to a conclusion - if it says "don't remove to-be-triaged without a replacement tag to say what the triage outcome was" that may be for the best. I'll admit that it may have been said already and I may have missed it in which case fault would lie with me, but reminding people would still be a good thing. On this specific case. There is a general presumption in PowerShell that if a cmdlet returns an object of type X, then things done with the properties and methods of X are done with the returned object outside the cmdlet. We teach people once that string has .Trim, .Split .Replace, ToUpper etc and for any command (cmdlet, function, script, external exe) returning a string One can argue that a need is so great that an exception should be made. Experience has taught me things about Read-Host which make think it has a particularly weak case for exceptions, but other people could say "No, there are all these people using read-host and they need to use trim (and only trim) in all these places and there would be HUGE upside". I was fairly sure the lack of visible evidence for that was because the need was small. . This could have been answered with something as simple as OP: "Hi, I'm new and maybe all the old hands have learned to tolerate something that should be fixed, but it seems to me Read-Host should have a switch for this thing that strings need to do afterwards " What we have had instead has wasted many hours. I see that in a pretty bad light, but if I make code-of-conduct complaints it's simply going to prolong things, and anyone investigating will probably say it's six of one and half a dozen of the other, and I shouldn't feel the obligation to respond which I appear to. |
@jhoneill, by and large I appreciate the measured response and the accountability regarding the label, but let me address some important points: On the meta aspects:
Fundamentally, if a better way forward emerges from this, the effort wasn't wasted.
Frankly, the only code-of-conduct complaint that would have been appropriate in the context of this thread is against yourself, for unwarranted threats with the code of conduct and accusations of trolling. It is indeed your choice whether to respond, though doing so in good faith is always preferable, as long as there actual differences to resolve (as opposed to something having devolved into bickering). I can fully appreciate the need to weed out issues ahead of time, so they don't require discussion in a quorum, which includes:
Clearly, the latter has not happened here.
I've addressed this before, but let me try again:
It is precisely because what are to me misreadings of a feature request can occur that it is important not to operate on such general rules, especially not unilaterally. To recap: The larger issue here is not that you expressed an opinion on the feature request at hand, but that:
The combination of these two actions in effect would have made this feature request die on the vine, with you as the sole arbiter. Even if the removal of
Is there any other way to read this than that you're thinking of yourself as the gatekeeper of what does and doesn't get discussed by the quorum of members? Sure, there's no obligation for any single WG member to be in charge of assigning the
What I think is inappropriate is to use deliberate withholding of the My reading of the WG document is that
|
Another 750 words. It is time to ask those who determine what is and is not trolling to give an opinion. |
@SteveL-MSFT, I'd like to add the following to my complaint above:
|
Code of conduct talks about
Let's just leave repo maintainers to decide what qualifies and what does not. I feel like I am the subject of vendetta, and they can tell me if I am right or wrong to feel that way. WG members do not decide who speaks - that is neither practical nor desirable -but they do decide who the WG listens to and which topics are put before their fellow members. Somewhere I saw "Gatekeeper" used in its pejorative sense. We are portiers, commissionaires our job is to get people in, but we can't do that for everyone. I feel like the nightclub door man who turns one customer away only to be glassed by someone who happened to be passing looking for a fight. In hindsight the initial " from that perspective nothing that can be implemented in PowerShell code - no matter how cumbersome and non-obvious - constitutes a workaround." should have been a warning that the issue was being trolled. WG membership does not prevent anyone observing that at some volume "carefully crafted arguments" serve no purpose other than to disrupt, and remarking when in their view that volume has been passed. If those in charge of the WG think I acted in bad faith they will fire me. The repeated complaint that my actions with tags were not taken in good faith has not resulted in my being told I should have done anything differently, so to the best of my knowledge what I did was legitimate. I have asked the repo maintainers to rule on whether I have good cause to feel harassed (e.g. the opening of two other issues as thinly veiled, but clearly directed attacks), and if sufficient volume of sufficiently argumentative posts amounts to disruptive behaviour, whether that has been passed. They may say no to both. As I said already I'm leaving it to them. |
|
|
This comment was marked as resolved.
This comment was marked as resolved.
|
This comment was marked as resolved.
This comment was marked as resolved.
Is there a good reason for your continued trolling? Please stop. If you can’t, then maybe it is time to block you. Your comments in this thread are unhelpful,passive agressive trolling. This really needs to stop. |
Not only was their no continued trolling, there was never any trolling to begin with (more on that below). I firmly believe my comments in this thread to be helpful to the community at large, long-term, as they raise important question about tagging, issue triaging, complaint resolution on which community consensus should be reached, and the conclusions should be added to the WG document. By contrast, unhelpful and passive aggressive does describe your comment and several ones you made in #19730, culminating in this defiant, argument-free comment. But I generally don't think blocking you or anyone else would be the right answer, and, as argued before, it is inappropriate for WG members to block community members, just because these members post comments they dislike and/or misconstrue them as personal attacks. (If members engage in actual CoC violations, then those violations must be dealt with as such.) @jhoneill's re-posting of his decision not to engage anymore is - to me - inherently unhelpful as well, so I pointed that out and I offered to clean the unnecessary comments up. When that offer wasn't taken, I hid my comments, which is the next best thing - you may have noticed that the comments were already hidden at the time you commented. |
I know this isn't pleasant, and it wasn't my preference to continue this publicly after no shared understanding about WG-member conduct could be reached here, hence my request in #19730. Since #19730 may take a while to resolve and I knew you had seen this thread, I decided to complain somewhat publicly here, as to me the matter has some urgency. It is unfortunate that #19730 and #19731 are now linked to this issue (one by explicit comments, the other by link only), but that wasn't my choice - in fact, I deliberately wanted to avoid it. So here we are, with my asking to add another complaint to the list:
As noted, I'm also hoping that the behaviors I have complained about here are added as DO NOTs to the WG document. |
This comment was marked as abuse.
This comment was marked as abuse.
@SteveL-MSFT, to bring closure to this issue:
As noted in #19730, I do hope that additional DON'Ts proscribing the behaviors complained about in this thread are added to the WG section of the governance document. |
One more thing, unfortunately: @doctordns has now inappropriately blocked me too. |
So perhaps |
@Andrew74L, on a quick meta note: Unless someone formally appeals the WG decision to decline this request (by @-mentioning the committee and making a focused argument), this request is in effect dead (Given what unfolded here, I definitely won't do that.)
I fully agree, and I've mentioned it before, but the reason I didn't suggest it as a solution is that it is technically a breaking change; from that perspective, a That said, at least potentially - I don't have a good sense of whether it would apply here - it could be considered a breaking change that falls into bucket 3: Unlikely Grey Area which would make it acceptable. |
This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes. |
@PowerShell/powershell-committee discussed the topic of a number of reported abuses (10 incidents) and whether they broke the Code of Conduct and what appropriate action should be taken. We do not take the Code of Conduct lightly and letting conversations that break the Conduct may be impacting our ability to attract new community members who only see the negativity that is presumed to be passively allowed. We want our community and our GitHub repos to be a safe place for professional discourse. We reviewed each individually reported comment (across different issues) and agreed that the comments violated the Code of Conduct. Each violator has been blocked from the PowerShell org on GitHub for 30 days. |
@SteveL-MSFT, please see #19730 (comment) |
Summary of the new feature / enhancement
Can you add an optional parameter to Read-Host to automatically remove leading & trailing whitespace (string.trim())?
Sometimes users accidentally add white space that can cause string comparisons to fail. Since whitespace is invisible, it sometimes can take a few minutes to figure out why the failure is happening.
Proposed technical implementation details (optional)
No response
The text was updated successfully, but these errors were encountered: