.sh output to .txt file - what am I doing wrong?

Question

I am running Windows 10 and am trying to save the error output of a test.sh file to a text file. So I created the test.sh file and wrote an unkown command in it (i.e. "blablubb").

After that I open the terminal (cmd.exe), switch to the directory and type test.sh 2>> log.txt.

Another window opens with "/usr/bin/bash --login -i \test.sh" in the title bar, shows me "bash: blablubb: command not found" and then closes immediately.

I want to save that output because the bash-window just opens for a split second. Every google search brings me to websites talking about redirecting the output and that Stream2 ist STDERR and therefore I should use test.sh 2>> log.txt or something smiliar that takes care of the STDERR stream.

If I try the same with a test.sh file and the content:

#!/bin/bash echo hi there

I get the output in the briefly open bash-window:

bash: #!/bin/bash: No such file or directory hi there

But the log.txt file is empty.

If I only have echo hi therein the test.sh file I get bash: echo: command not found in the bash-window. The log.txt also empty.

If I type the following directly in the terminal, the output is written in the log.txt:

echo hi > log.txt 2>&1

If I type directly in the terminal:

echdo hi > log.txt 2>&1

I get 'Der Befehl "echdo" ist entweder falsch geschrieben oder konnte nicht gefunden werden.' in the log.txt file.

So I guess the redirecting of the output works fine until I use test.sh. I know that .sh files are something from the unix world and that the problem might lie there but I don't know why I can not redirect the output briefly shown in the bash-console to a text file.

Answer 1

It would help to know if you are running Windows Subsystem for Linux (Beta). Or if you are doing something else. I'm assuming this is what you are doing on windows 10.

If this is the case are you using bash to run the script?

Are you using win-bash?

If it is win-bash I'm not very familiar and would recommend Windows Subsystem for Linux (Beta) for reasons like this. win-bash, while cool, might not be compatible with redirection operators like 2>>.

You have stdout and stderr, by default (if you don't specify) the >> (or append) will only append standard output into the txt file.

If you use 2 it will append the standard error into the txt file. Example: test.sh 2>> log.txt

This could be better described at this site.

To get exactly the command for append both stdout and stderr, go to this page.

Please tell me if this doesn't answer your question. Also, it could be more valuable to attempt a search for this answer first and explain why your search found nothing or give more extensive clarification as to what the problem is. I love answering questions and helping, but creating a new forum page for what might be an easy answer may be ineffective. I've had a bunch of fun with your question. I hope that I've helped.

Answer 2

The 2>> redirection syntax only works if the command line containing that syntax is interpreted by bash. So it won't work from the Windows command prompt, even if the program you are running happens to be written in bash. By the time bash is running, it's too late; it gets the arguments as they were interpreted by CMD or whatever your Windows command interpreter is. (In this case, I'm guessing that means the shell script will find it has a command line argument [$1] with the value "2".)

If you open up a bash window (or just type bash in the command one) and then type the test.sh 2>>log.txt command line in that shell, it will put the error message in the file as you expect.

I think you could also do it in one step by typing bash -c "test.sh 2>>log.txt" at the Windows command prompt, but I'm not sure; Windows quoting is different than *nix quoting, and that may wind up passing literal quotation marks to bash, which won't work.

Note that CMD does have the 2>> syntax as well, and if you try to run a nonexistent windows command with 2>>errlog.txt, the "is not recognized" error message goes to the file. I think the problem comes from the fact that CMD and bash disagree on what "standard error" means, so redirecting the error output from Windows doesn't catch the error output by bash. But that's just speculation; I don't have a bash-on-Windows setup handy to test.

Answer 3

That's makes a lot of sense. Thanks Mark!

Taking what mark says into account I would get Windows Subsystem for Linux (Beta). There are instructions here. Then run your script from there.