Repository navigation
Make the new, future no-profile CLI for use in shebang lines implement other CLI fixes too #8072
Description
Follow-up from a conversation with Steve Lee (@SteveL-MSFT) in #7989.
PowerShell's existing CLI has a number of problems, relating to:
- (a) unconditionally dot-sourcing
$PROFILE, making for unpredictable execution environments - see #!/usr/local/bin/powershell bang should not load profile #992 - (b) parameter syntax and parsing, both in general and with respect to fitting into the Unix world - see Align PowerShell's CLI / startup behavior with POSIX-like shells such as Bash - command-line arguments #3743
- Update: One of the problems in the linked post may get fixed int the existing CLI, via a new parameter, namely if the experimental
PSCommandWithArgsfeature becomes a stable one.
- Update: One of the problems in the linked post may get fixed int the existing CLI, via a new parameter, namely if the experimental
- (c) unhelpful mapping of PowerShell's output streams to the outside world's standard streams - see Mapping file descriptors of pwsh process to Powershell streams #7989
The 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 $PROFILE in 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-np needs revising, however.
Environment data
Written as of:
PowerShell Core 6.1.0
Activity
SteveL-MSFT commentedon Oct 19, 2018
Whatever name we choose, we also need to consider
pwsh-np-previewmklement0 commentedon Oct 19, 2018
I don't understand, Steve Lee (@SteveL-MSFT): why
*-preview?SteveL-MSFT commentedon Oct 19, 2018
Michael Klement (@mklement0) we want to maintain a consistent separation of the stable and preview releases so I would think we'd have
pwsh,pwsh-previewlike we have today, along withpwsh-npandpwsh-np-previewmklement0 commentedon Oct 21, 2018
Ah, of course, thanks Steve Lee (@SteveL-MSFT).
Any thoughts on a suitable new name that reflects the scope and intent of the changes?
psh, perhaps? (OK, just kidding).Naming is tricky, because the name should be kept short, so I fear it'll come down to documenting things well.
pwshc? (with thecstanding for (a proper) CLI).tbakerweb commentedon Feb 2, 2020
Hey Steve Lee (@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!
sdwheeler commentedon May 29, 2024
Michael Klement (@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.