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

[mklement0]

^{Follow-up from a conversation with @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 PSCommandWithArgs feature becomes a stable one.
• (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

[SteveL-MSFT]

Whatever name we choose, we also need to consider pwsh-np-preview

[mklement0]

I don't understand, @SteveL-MSFT: why *-preview?

[SteveL-MSFT]

@mklement0 we want to maintain a consistent separation of the stable and preview releases so I would think we'd have pwsh, pwsh-preview like we have today, along with pwsh-np and pwsh-np-preview

[mklement0]

Ah, of course, thanks @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 the c standing for (a proper) CLI).

[tbakerweb]

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!

[sdwheeler]

@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.