Is there a way to tee stderr from a command that's redirecting error to a file?

I'm not a complete novice at unix but I'm not all that advanced either. I'm hoping that someone with a little more knowledge than myself has the answer I'm looking for.

I'm writing a wrapper script that will be passed user commands from the cron...

Ex:

./mywrapper.sh "/usr/bin/ps -ef | grep foo > log/ps.out 2>&1"

The wrapper will execute them from the cron and log start and stop times and any errors or exit codes.

Question:
However in the case as above that a user is redirecting their errors to their own log file is there a good way to sample the error such that both the user log and the wrapper log get the error message?

Let me know if you need more info, thanks!

Currently I am grabbing the stderr away from the user command and sending it to a temp file. However this method removes the error from the user log.

Ex:

eval "$1 2> temp.err"
ERR=`cat temp.err`
rm temp.err

I have come to a solution but I doubt I will use it since it involves editing users commands dynamically.

My solution comes in two parts:

  1. Use a recursive function to track down any error redirection in the issued command:
  • Return nothing if redirection is not taking place
  • If redirection is to another channel (Ex: Stdout is channel 1) call the function again on the new channel, if the function returns nothing pass the channel otherwise pass the returned value
  • Return the file being redirected to if there is one
  • Return null if the user is redirecting to /dev/null or has turned off that channel(Ex. #>&-)
  1. Use named pipes created from the mkfifo command to redirect errors from the users command to both the user file and a temp file to use by the wrapper.

Then when I think about redirection happening before a pipe

Ex:

du -sk /path/* 2> log/du.err | sort -rn > log/sort.log 2>&1

Now I would need to run the command through a loop and do this process for each piped command, creating a named pipe for each redirection.

If someone sees an easier way great but this is the only way I see to do it. It's my opinion that telling users the errors will be located in a master log file will be easier.