Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am a database administrator working with DB2 on AIX. (Please continue to read as this is related more to ksh than DB2, otherwise I would have posted this over on dba.stackexchange.com.) I am attempting to write up ksh scripts for several of our database deployment as well as database maintenance scripts.

I am in the process of putting error handling in our scripts to know whether or not something requires a hard fail or just a warning message, or can be ignored.

With most AIX/ksh related tasks I can check $? = 0, but not so with DB2. Unless the database engine fails, I will never get anything but a zero. DB2 will, however, pass back to the console its error/warning/info codes.

Since I know I can get at those codes via the console, I have been trying to capture whatever is on the console for specific command to DB2. Once I have that, I have been sending that output to a function where I use egrep and regular expressions to determine if I need to fail (exit 1), or succeed (exit 0) within my script. I also tend to pipe all output from my script to tee, since several of my scripts are long and/or call into multiple other scripts. This way I have a record of the entire "job" that ran both for reference, as well as for troubleshooting my scripts.

Recently, I learned I can ksh blah.sh 2 > &1 | tee mylog in order to make sure I capture syntax errors with my script.

I am wondering, what is the best way to handling this kind of error parsing in ksh? I have tried to feed a command to DB2 with the -v option (which is supposed to play the command back to the screen as well as the results of the command) and put that in a variable, but then I actually don't get the command outputted to the screen. Example:

RESULT=$(db2 -v drop table blah)

I end up having to cat ${RESULT} in order to get my screen print for my above pipe to tee and then I still have to pass RESULT to my parsing function.

Another thing I have tried is piping the result of my command to a file as well. Example:

db2 -v drop table blah | tee myResult

This will output to the screen for my high level tee, but now I have an extra file on the file system I have to worry about cleaning up afterwards (though I can egrep and cat it with no issues). And if my job ever crashes piping to tee in script and is itself being piped to tee results in some funky behavior (works fine if it succeeds without crashing). This leads me to believe that the double pipe to tee is not the best option.

Someone has mentioned to me the script command, but I'm not sure if that will help or not?

Any ideas or thoughts? I am assuming I'm not the only one looking to use "screen capture" of specific commands for error parsing while still piping everything to tee for an entire job run.

Also I tend to invoke sub shells with my sub scripts instead of calling them as if in the same shell (ie, ksh blah.sh vs . ./blah.sh). It has seemed to work the best for my scripts. Not sure if that impacts any answers or not.

Any direction based on experience would be appreciated.

share|improve this question
    
Check script but again you have an extra file on your system to worry about. –  jippie Dec 27 '12 at 21:59
    
I would suggest learning PERL where you can specifically open the file being written and just read from it directly and parse the text, which is what PERL was designed to do. –  Karlson Dec 27 '12 at 22:07
    
@Karlson Perl is not an acronym and should not be all caps. Shell utilities such as awk can read files and parse them as well. –  jordanm Dec 28 '12 at 6:06
    
@jordanm Old force of habit. –  Karlson Dec 28 '12 at 14:05
    
I think Perl is definitely a possible choice. The trick here is I am up against having to write these scripts with a month before "go live" of a piece of software. I am one of the first three DBA's our company has. So I may not have the time to learn Perl before go live. After go live, I may have the time to look into that. –  Chris Aldrich Dec 28 '12 at 14:05

1 Answer 1

up vote 1 down vote accepted

There is no reason to use tee or script. Unless you are looking to do the analysis after the fact and offline.

script will capture the text output of your shell session and put it into a file typescript by default but not necessarily. Appending or overriding is up to you.

tee allows you to dump output of the running command to a file and to allow it to show on the screen as well.

My personal preference would be to have:

<command> 2>&1 > <filename>

if you need logs of the transactions which you can later analyse. If you need to analyse them while the command is running that would be smarter then simply dumping output into a file:

<command> | <script> 2>&1 > <filename>

This way you can have the script dump the output selectively or completely into a file and perform other tasks like notification (email, sms, paging, monitoring software notification) without stopping the command.

If you want to watch what is happening now within the file, then put the job in the background:

<command> 2>&1 > <filename> &

and just tail the

tail -f <filename>

I would assume the output is text and not just message codes.

share|improve this answer
    
Output is text and message codes. –  Chris Aldrich Dec 28 '12 at 17:27
    
do if i did db2 -v drop table mytable 2 > &1 > resultsFile &, That will write to the console AND the file? –  Chris Aldrich Dec 28 '12 at 18:49
    
No it will write only to the file. The tail -f resultsFile will allow you to see on the console what's being written and take action. –  Karlson Dec 28 '12 at 18:57
    
Actually...I do need to do analysis offline and after-the-fact. –  Chris Aldrich Dec 31 '12 at 11:46
    
@ChrisAldrich If all you're looking for is doing the analysis offline then dump the output to a file and analyze it after. –  Karlson Dec 31 '12 at 13:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.