Make the new, future no-profile CLI for use in shebang lines implement other CLI fixes too #23872

^{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 has been mitigated in the existing CLI in v7.5 (since preview 5), albeit not in a syntax-compatible way, because a new parameter, -CommandWithArgs was introduced that allows treating the first subsequent argument as a script to which all the remaining arguments are passed as arguments.
• (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
• (d) the unhelpful pseudo-interactive behavior of -File - that contravenes expectations with respect to providing code via stdin - see CLI: pwsh -Command - and pwsh -File - unexpectedly exhibit pseudo-interactive behavior, lack support for argument passing #3223

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