4

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!

Community
  • 1
  • 1
Karl Yngve Lervåg
  • 1,714
  • 3
  • 18
  • 34
  • Why are you using ">&" if you don't want stderr to go to the output file? – Paul Tomblin Jan 15 '09 at 15:28
  • The segmentation fault that stops the program from running is not outputted by the program itself. I do not know why this is so, but it means that I don't care about the stderr of the program (and that is why I use ">&"), but of the script itself. – Karl Yngve Lervåg Jan 15 '09 at 15:33
  • Wont the signal still stop your program even though you redirect stderr to /dev/null? How can that help? either way, shouldn't you exec 2>/dev/stderr to get it back to stderr? – jishi Jan 15 '09 at 15:36
  • First: Thanks for the comment about /dev/stderr (that was actually what I wanted all along)! Second: You are right, the program will stop. The thing is: I don't care about the program, I only care about the output. I don't want to see the program errors until I open the file 'run.txt'. – Karl Yngve Lervåg Jan 15 '09 at 15:44
  • I bet you if you took out that ">&" you wouldn't have to all this messing around with exec. ">&" say to redirect stdout and stderr into the file. If you just used ">", stdout would go to the file and stderr would go to the screen. – Paul Tomblin Jan 15 '09 at 15:45
  • Yes, but I don't want stderr to go to the screen. I want stderr to go to the file, and with I achieve this with ">&". – Karl Yngve Lervåg Jan 15 '09 at 15:51

2 Answers2

8

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
  • 494
  • 1
  • 4
  • 14
0

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
  • 179,021
  • 58
  • 319
  • 408
  • 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 Jan 15 '09 at 15:22
  • 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 Jan 15 '09 at 15:27
  • 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 Jan 15 '09 at 15:29