Hacker News Reader

Comment by raincole | Hacker News Reader

The comments on stackoverflow say the words out of my mouth so I'll just copy & paste here:

> but then shouldn't it rather be &2>&1?

> & is only interpreted to mean "file descriptor" in the context of redirections. Writing command &2>& is parsed as command & and 2>&1

That's where all the confusion comes from. I believe most people can intuitively understand > is redirection, but the asymmetrical use of & throws them off.

Interestingly, Powershell also uses 2>&1. Given an once-a-lifetime chance to redesign shell, out of all the Unix relics, they chose to keep (borrow) this.

View on HN

PowerShell actually has 7 streams. Success, Error, Warning, Verbose, Debug, Information, and Progress (though Progress doesn't get a number) https://learn.microsoft.com/en-us/powershell/module/microsof...

Although PowerShell borrows the syntax, it (as usual!) completely screws up the semantics. The examples in the docs [1] show first setting descriptor 2 to descriptor 1 and then setting descriptor 1 to a newly opened file, which of course is backwards and doesn't give the intended result in Unix; e.g. their example 1:

  dir C:\, fakepath 2>&1 > .\dir.log

Also, according to the same docs, the operators "now preserve the byte-stream data when redirecting output from a native command" starting with PowerShell 7.4, i.e. they presumably corrupted data in all previous versions, including version 5.1 that is still bundled with Windows. And it apparently still does so, mysteriously, "when redirecting stderr output to stdout".

[1] https://learn.microsoft.com/en-us/powershell/module/microsof...

IIRC PowerShell would convert your command's stream to your console encoding. I forget if this is according to how `chcp.com` was set or how `[Console]::OutputEncoding` was set (which is still a pain I feel in my bones for knowing today).

It's also not a file descriptor. It's a PowerShell Stream, of which there are five? you can redirect to that are similar to log levels.

I don't get the confusion.

You redirect stdout with ">" and stderr with "2>" (a two-letter operator).

If you want to redirect to stdout / stderr, you use "&1" or "&2" instead of putting a file name.

The way I read it, the prefix to the > indicates which file descriptor to redirect, and there is just a default that means no indicated file descriptor means stdout.

So, >foo is the same as 1>foo

If you want to get really into the weeds, I think 2>>&1 will create a file called 1, append to a file descriptor makes no sense (or maybe, truncate to a file descriptor makes no sense is maybe what I mean), but why this is the case is probably an oversight 50 years ago in sh, although i'd be surprised if this was codified anywhere, or relied upon in scripts.

I agree that it adds to the confusion, but note that `file1>file2` also wouldn’t work (in the sense of “send the output currently going to file1 to file2”) and isn’t symmetrical in that sense as well. Or take `/dev/stderr>/dev/stdout` as the more direct equivalent.

Isn't that because of posix?

Powershell is not posix compliant and does not pretend to be. Like conditionals using `()` instead of `[]` is already a clear departure from posix

Don't know if this is definitive, but:

https://www.johndcook.com/powershell.html#:~:text=The%20core...

POSIX Korn shell, specifically, according to Wikipedia:

https://en.wikipedia.org/wiki/PowerShell#Grammar

so maybe it inherited 2>&1 from Korn shell, which in turn was POSIX.

But yeah, Powershell was not built purely to be a POSIX shell, but I thought it tried to be compatible where it made sense (hence the seeming clash of cultures).

I don't think they were talking about pwsh? pwsh actually has types and is its own programming lang unlike *sh, so it doesn't rely on builtin command exit codes.

Reply on news.ycombinator.com