-
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
$ErrorActionPreference = 'Stop'
ignored, when command read from stdin.
#21808
Comments
There is a consistency rather than being completely broken. Consider
Results in
My explanations often start with PowerShell is not a UNIX shell. UNIX programs are pipe/stream based, PowerShell is record based. Now consider each line in stdin as its own record and executed one after the other, however in the same session so the state accumulates, so setting So notice that the |
The stdin reader acts like the command line repl so things like I find when you want to use pwsh -NoProfile -NoLogo -Command - << EOF
& {
code here
}
EOF You still need the trailing newlines to ensure PowerShell sees the end of the |
Indeed, as discussed in the previously mentioned #3223 and in #15331, both
Given the desire to maintain backward compatibility, these behaviors won't change, though even in the context of this behaviors there are two bugs:
In other words: the following should print # From Bash
pwsh -NoProfile -NoLogo -Command - <<'EOF'
& {
1 -eqFOO 1
}
EOF
echo $? Taking a step back:
|
Which would be fine, if PowerShell really always did it like that, but it doesn't. If I execute the whole thing as one string (with newlines) passed as single argument to IMO it simply never makes sense to have the exactly same script behave completely different depending on how it's read. Now as @jborean93 and @mklement0 mentioned, the stdin reader apparently behaves like some semi-interactive prompt. As you might have guessed, I come from the Linux world, where a program in such a case would check whether stdin is connected to a terminal or not. Even if it's decided that this is in fact the desired behaviour, there should IMO be quite some warnings about it in the help texts to
Well, in the end it's your decision, and if there'd be some warning in the description of these options which tells about the behaviour I'd also consider the issue as "solved", but... From a perspective of what's common sense and assuming that PowerShell will be a long time around, I would suggest to rather do the compatibility break[0] now than live one with something that is in itself inconsistent[1]. [0] And do you really think that a lot people actually depend on that behaviour? I mean it's even not documented as it actually behaves, so anyone depending on this would already use it by accident. Plus what sense would it make to use [1] Cause you'd then have |
I hear you - #3223 pretty much argued the same points. I have no say in what technically breaking changes are considered acceptable; my previous comment links to at least one instance of existing code that would break. 🤞that at least |
I think it's more than a bucket 3 breaking change to change the |
I mostly meant what comes out of As for That way, any current user would fail fast and could quickly adapt their code, without any silent issues. One could further argue, that at least for Anyway... I'm now simply using multi-line strings (instead of here-documents) to pass a script to PowerShell via |
Command-specific help topics as well as conceptual help topics including the one for the CLI, about_Pwsh, are maintained both online and - assuming you've run However, a duplicate of the content of about_Pwsh is also baked into the @SteveL-MSFT, personally I think that fixing the problem in the context of As for what could be done if backward compatibility were NOT a concern (a collection of proposed breaking changes can be found in #6745, but there are no plans for a version allowed to make such fundamentally breaking changes):
|
I agree that adding a new parameter makes more sense than changing behaviour as can then be better documented than this current mix of semi-broken expectations vs how PowerShell currently works which gives this mixed outputs. Interactive-UX WG (which I can't make) will be discussing this later tonight so expect a response from one of the rest of the WG on this |
@philcerf - Thank you for this issue. The existing -command and -file were not intended for this scenario. The WG is not certain that the new scenario is needed since other ways are available to achieve this behavior. We would need to see more compelling use cases to consider adding a feature for this use case. We will update the documentation (Thank you @mklement0 ) to explain the current behavior. |
This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes. |
This issue has been marked as by-design and has not had any activity for 1 day. It has been closed for housekeeping purposes. |
📣 Hey @philcerf, how did we do? We would love to hear your feedback with the link below! 🗣️ 🔗 https://aka.ms/PSRepoFeedback |
Prerequisites
Steps to reproduce
Hey.
Another issue when reading the commands from stdin, possibly related to #21784.
Consider something like:
This exits on the error and
BLA
is not written.The same when the command is given as argument but with newlines in it:
Now when read from stdin:
gives:
However:
works as expected and does not print
BLA
:WTF?! ... Reading commands from stdin seems basically completely broken.
Expected behavior
reading commands from stdin should work as if given as `-Command` argument.
Actual behavior
it's completely broken
Error details
No response
Environment data
N/A
Visuals
No response
The text was updated successfully, but these errors were encountered: