Describe the bug

Using out>, err>, or any of the other spellings, it is not considered an error to do so without providing an actual pipe redirection target, and the redirection is silently ignored.

How to reproduce

1. In a terminal, run something like

   ^cargo invalid-command o+e> | ignore

2. Note that stderr is printed to the terminal.
3. Compare to running with run-external --redirect-combine, e.g.

   run-external cargo invalid-command | ignore

4. Run something like just ^echo o+e>; note that the o+e> is not passed through as an argument to the external command.

Expected behavior

Redirection should be an error if no redirection target is provided.

Alternatively, allow and actually support explicit redirection into a pipeline, i.e.

• ^cmd | pipeline does run-external --redirect-stdout
  • exception: ^cmd | complete | pipeline does run-external --redirect-stdout --redirect-stderr
• ^cmd out> | pipeline does run-external --redirect-stdout (even when completed)
• ^cmd err> | pipeline does run-external --redirect-stderr (even when completed)
• ^cmd o+e> | pipeline does run-external --redirect-combine (even when completed)
• ^cmd o> e> is an error; suggests to use o+e>

You could think of > syntax as being special flag syntax that gets passed through to run-external for ^commands. (Does do { print hi } o> out.log work?) Though complete does still sort of magically change how the previous item in the pipeline gets handled. It might make sense to have a combine which pipes stdout and stderr combined onto the pipeline without waiting for completion like complete does.

It's ultimately about managing the three ways commands in nushell can output data — print (stdout), print -e (stderr), and return (pipeline) — and bridging external commands which only have stdout/stderr with the pipeline.

Configuration

(issue was created from mobile; will edit this in later)

Additional context

• see also Permit combining stdout/stderr as streams to external command behind pipe #9673