Make the new, future no-profile CLI for use in shebang lines implement other CLI fixes too #23872
Replies: 7 comments 4 replies
-
|
Whatever name we choose, we also need to consider |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand, @SteveL-MSFT: why |
Beta Was this translation helpful? Give feedback.
-
|
@mklement0 we want to maintain a consistent separation of the stable and preview releases so I would think we'd have |
Beta Was this translation helpful? Give feedback.
-
|
Ah, of course, thanks @SteveL-MSFT. Any thoughts on a suitable new name that reflects the scope and intent of the changes?
Naming is tricky, because the name should be kept short, so I fear it'll come down to documenting things well.
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @SteveL-MSFT, It isn't clear in this issue, could you please specify if/when/where the Streams output to the associated File Descriptors from #7989 will show up. I'm very interested in this feature and was quite sad when I realized it didn't already exist :(. Thanks for your contributions! |
Beta Was this translation helpful? Give feedback.
-
|
@mklement0 Thanks for collecting these issues in one meta-issue. All of the linked issue have been closed but there is room for more discussion. The WG reviewed this and decided it would be better served by moving this issue to a GitHub Discussion where the community can help us with requirements and decisions for a future solution. |
Beta Was this translation helpful? Give feedback.
-
|
Given this discussion was started six years ago, I think the future has been and gone. May I suggest that the current process is not working for this component? I propose that people build examples/proofs of concept completely independently of this project/repository. There is no restriction on anyone writing a command line program that uses the SDK. For example I have one that meets my needs. |
Beta Was this translation helpful? Give feedback.
-
|
Generally speaking, it is a logical fallacy to dismiss proposals based on the lack of activity around them, as opposed to dismissing them based on their (lack of) inherent merit. It's fine to suggest pragmatic alternatives, but doing so doesn't warrant championing them as the only way forward. If you see value in the proposal at hand, express it as such. |
Beta Was this translation helpful? Give feedback.
-
|
I am not dismissing the proposal, I am offering an opinion as to a way forward as I thought that was acceptable given it was moved to discussions. |
Beta Was this translation helpful? Give feedback.
-
|
The only implied stance you've taken with respect to the proposal is "since no one's paying attention, let's move on" - my point is that this is a false dichotomy. |
Beta Was this translation helpful? Give feedback.
-
No, my position is so lets do something about it. Get some prototypes, prove the concepts work, prove they don't break scp etc. |
Beta Was this translation helpful? Give feedback.
-
Follow-up from a conversation with @SteveL-MSFT in #7989.
PowerShell's existing CLI has a number of problems, relating to:
$PROFILE, making for unpredictable execution environments - see #!/usr/local/bin/powershell bang should not load profile #992-CommandWithArgswas introduced that allows treating the first subsequent argument as a script to which all the remaining arguments are passed as arguments.-File -that contravenes expectations with respect to providing code via stdin - see CLI:pwsh -Command -andpwsh -File -unexpectedly exhibit pseudo-interactive behavior, lack support for argument passing #3223The existing CLI cannot be fixed so as not to break backward compatibility, but it was agreed that (a) would be fixed by way of a new, separate executable/symlink, notably for use in shebang lines of stand-alone shell scripts on Unix-like platforms.
More broadly, however, this new CLI is an opportunity to fix (b) and (c) as well, which would go a long way toward endearing PowerShell to CLI-savvy Unix users.
Essentially, it would provide a new CLI that is a well-behaved cross-platform citizen with sane defaults.
(As such the profile-loading behavior should mimic Bash's - only load
$PROFILEin interactive shells by default).Note: The new behavior needn't be a separate binary: The behavior variation could be triggered by invocation via symlink whose name indicates the need to apply alternate behavior, at least on Unix-like platforms. (Invoking .NET Core executables via symlinks on Windows is not yet supported, but will hopefully come in .NET Core 3.0 - see https://github.com/dotnet/core-setup/issues/4080)
Given the then-broader scope, the originally proposed name
pwsh-npneeds revising, however.Environment data
Written as of:
Beta Was this translation helpful? Give feedback.
All reactions