-2

I already know the proper way to redirect stderr and stdout in CMD and BASH. Trying to get an understanding of the logic of the various shells/environments etc. In previous discussions on this topic, people were using some form of logic to explain why/how it works in a specific shell/environment. But that logic doesn't apply across the various shells/environments. Since the logic applied for one doesn't hold up for the other then logic applied to any of these is inadequate. And that is what makes it confusing for a noob such as myself. I'm getting a little deep here though. When reading about redirection, I ran across this example for CMD/batch in windows, and appears to be very similar behavior in Bash:

command > file 2>&1

In the documentation it states that is the correct way to redirect stderr to stdout and then stdout to a file. It also seems that one would tend to choose

command 2>&1 >filename

but this syntax will fail. After way to much time spent trying to understand the logic of this and finally coming to terms with it, I run across this world crashing example for powershell:

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

This clearly goes against the logic for the former examples. This topic has been beaten to death it appears, even on this site. So if using "logic" and it doesn't apply to other shells how do folks manage to remember these subtle differences between shells?

djhurt1
  • 5
  • 4
  • 3
    "It also seems that one would tend to choose `command 2>&1 >filename`" -- why would you say that? – glenn jackman Aug 09 '23 at 17:38
  • 1
    Bash makes perfect sense when you consider the Unix process model that implements it. `cmd.exe` (via `command.com`) tried to mimic Unix on a system that was 1-2% the cost and computing power, so the similarities are extremely superficial. It's better not to try to find the common logic between the two, since one is logical while the other is merely trying to look similar. – that other guy Aug 09 '23 at 18:15
  • As a noob I hoped to find a common logic, if there is any. It appears that doesn't exist based on the comments so far.It's overwhelming to me to remember the subtle differences. Those of you that can float in and out of each language fluently is impressive. @glennjackman I said that because that's the way I wrote it first on my own. Then I find in several sources that will not work the way I thought it would. Googling it appears many others had the same thought logic as myself in how to write that. – djhurt1 Aug 09 '23 at 19:56
  • Keep in mind that it's strictly left-to-right: `cmd 2>&1 >afile` means: redirect file descriptor 2 to whatever fd 1 is currently pointing to (usually /dev/stdout), then redirect fd 1 to write to afile. Setting fd 1 does not change fd 2. It took me a long time to really understand that. – glenn jackman Aug 09 '23 at 21:05
  • I don't see the point in the comparision. If you then add csh or Tcl to your list, you will find still more differences. Different languages have different behaviour - similarities are in a way more surprising than differences. – user1934428 Aug 10 '23 at 07:23
  • So it appears to me, based on the comments here and other discussions, that to be fluent in one shell, you just need to read the documentation and throw out most of what you've learned for the others. You won't find a common logic between them. – djhurt1 Aug 10 '23 at 17:43

0 Answers0