views:

1739

answers:

2

Hello!

I have a simple script which is used to start another program. This other program may sometimes yield a SIGSEGV, which disrupts my output. I have therefore added a couple of lines which is supposed to temporarily redirect the stderr to /dev/null such that the SIGSEGV is ignored. The following is a draft of my code:

exec 2> /dev/null
progname >& ./tmp/run.txt && run_status='OK'
exec 2>1

The problem is that the last line does not do what I want. The first line obviously works, and redirects the stderr. The last line is supposed to return the stderr back to where it was before (which I have only supposed is the same as stdout).

Any help would be appriciated!

A: 

Why not just redirect it for the progname run only?

   progname > ./tmp/run.txt 2>/dev/null && run_status='OK'

Or possibly

{
   progname > ./tmp/run.txt && run_status='OK'
} 2>/dev/null
Paul Tomblin
That would have been a solution if it was the program itself which sent the error message to stderr. This is not the case, probably because when the program is interrupted by a SIGSEGV it stops before being able to output an error message. It is therefore redirected to the parent process.
Karl Yngve Lervåg
I think you don't know what you're talking about. Either the program outputs to stderr, or it doesn't. There is no "redirected to the parent process".
Paul Tomblin
Ah, sorry. I do not know what I am talking about, no. But I know that the program stops with a segmentation fault, and that it does not output to stderr. Also. the "parent process" (or what I should call it) is the one that outputs the segmentation fault to screen.
Karl Yngve Lervåg
+3  A: 

Another option is:

exec 3> /dev/stderr 2> /dev/null
progname >& ./tmp/run.txt && run_status='OK'
exec 2>&3

Or even

exec 3>&2 2> /dev/null
progname >& ./tmp/run.txt && run_status='OK'
exec 2>&3

That way the script preserves the separation of stdout and stderr for the script (ie. the scripts stdout and stderr can be redirected separately.

Magnus Hiie
Thank you, that solves the problem! :)
Karl Yngve Lervåg