3 ms·

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 t

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.

zwischenzug 8mo ago
Isn't that because of posix?
- TheDong 8mo ago
  Powershell is not posix compliant and does not pretend to be. Like conditionals using `()` instead of `[]` is already a clear departure from posix
  - b40d-48b2-979e 8mo ago
    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.
  - zwischenzug 8mo ago
    Don't know if this is definitive, but: https://www.johndcook.com/powershell.html#:~:text=The%20core%20of%20the%20PowerShell,1003.2%20standard%20for%20Unix%20shells. https://www.johndcook.com/powershell.html#:~:text=The%20core... POSIX Korn shell, specifically, according to Wikipedia: https://en.wikipedia.org/wiki/PowerShell#Grammar 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).
jcotton42 8mo ago
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/microsoft.powershell.core/about/about_output_streams?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...
xeyownt 8mo ago
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.
ptx 8mo ago
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/microsoft.powershell.core/about/about_redirection?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...
- b40d-48b2-979e 8mo ago
  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.
cesaref 8mo ago
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.
layer8 8mo ago
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.

zwischenzug 8mo ago

Isn't that because of posix?

TheDong 8mo ago
Powershell is not posix compliant and does not pretend to be. Like conditionals using `()` instead of `[]` is already a clear departure from posix
- b40d-48b2-979e 8mo ago
  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.
- zwischenzug 8mo ago
  Don't know if this is definitive, but: https://www.johndcook.com/powershell.html#:~:text=The%20core%20of%20the%20PowerShell,1003.2%20standard%20for%20Unix%20shells. https://www.johndcook.com/powershell.html#:~:text=The%20core... POSIX Korn shell, specifically, according to Wikipedia: https://en.wikipedia.org/wiki/PowerShell#Grammar 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).

jcotton42 8mo ago

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/microsoft.powershell.core/about/about_output_streams?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...

xeyownt 8mo ago

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.

ptx 8mo ago

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/microsoft.powershell.core/about/about_redirection?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...

b40d-48b2-979e 8mo ago
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.

cesaref 8mo ago

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.

layer8 8mo ago

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.