Tar with Shell Scripts

[Robert True]

I am trying to verify ignite tapes after writing with a ksh script and email the results, but I cannot manage to send the read of the tar archive on the tape to /dev/null so that it does not appear in the out going email.

Everything else is working, I know the ignite boot blocks are good, etc, it's just the tar archive read back that is the problem: too verboose. A pain to read at best, and usually gets trunciated by the MS exchange system anyway. Unfortunatly the read-back of the boot block is then lost also.

The vfy cmd used is:
/bin/tar tf /dev/rmt/0m 2>&1 > /dev/null

If I recall correctly from the very distant past, tar does not send the output to standard err under this situation, but how can I trap it? Any suggestions?

Thanks Rt.

[harry d brown jr]

To get error messages just PRETEND to restore a BOGUS file:

tar -xvf /dev/rmt/0m crazymanfilename 2>&1 | uuencode errors.txt | mailx -m -s "tar er
rors" youremail@yourdomain.com

You can get errors like:
tar: cannot open nxewtest.tar
or
Tar: error! blocksize changed
or whatever

live free or die
harry

[Steven E. Protter]

I would suggest on a spot with some free space

tar tf /dev/rmt/0m > testfile.txt

SEP

[Olivier Decorse]

ok,
2 possibilities :
1) after the tar command, verify the return status of the command (under ksh) :
/bin/tar tf /dev/rmt/0m 2>&1 > /dev/null
STATUS=$?
if [ $STATUS -ne 0 ]
then
echo "Problem with tar on `hostname`" |mailx -m -s "pbl with tar" your_name@your_address
fi
tar only retuns 0 if everything is ok ! I test with modifying an tar file and it returns : 3

2) modify your command line to extract any error :
/bin/tar tf /dev/rmt/0m > /dev/null 2> error_tar.txt
if [ -s error_tar.txt ]
then
echo "Problem with tar on `hostname`" |mailx -m -s "pbl with tar" your_name@your_address
fi
With my previous manually modification, error_tar.txt contains :
Tar: tape blocksize error

Hope this helps you !

Olivier.

[Sundar_7]

The problem is the order in which stdout and stderr is redirected.

Try this

/bin/tar tf /dev/rmt/0m >/dev/null 2>&1

This should work.

[Jeroen Peereboom]

You command should read
/bin/tar tf /dev/rmt/0m > /dev/null 2>&1

Or maybe even ..../dev/rmt/0mn .... for no-rewind device.
You may also send the output to a file, and send a line count (wc -l) in an email?
And the return code of the tar command too.

JP.

[Bill Hassell]

Just to explain why "2>&1 > /dev/null" and "> /dev/null 2>&1" are very different, this is what is happening: The shell processes file redirection left to right so 2>&1 >/dev/null says: take whatever stdin (descriptor #1) is and set stdout to the same fd. Then >/dev/null changes stdout to /dev/null but stderr is still going to whatever stderr was in the beginning. The effect (assuming default conditions) is that stdout goes to /dev/null and stderr goes to the terminal display.

In the second case, >/devnull changes stdout, then 2>&1 change stderr to match the current state of stsout, which is /dev/null. Note that there will be no output at all which not what is desired. I would redirect stderr into your email message and let stdout go to your email. That way, you'll get the tar error messages but the table of contents will be sent to /dev/null.

One other note: /bin has been gone for more than a decade. Just like Solaris and other SysV Unices, the v.4 filesystem layout has obsoleted /bin and /lib. They are now /usr/bin and /usr/lib. The reason things seem to work OK is through the use of transition links:

ll -d /bin /lib
lr-xr-xr-t 1 root sys 8 Oct 29 2003 /bin@ -> /usr/bin
lr-xr-xr-t 1 root sys 8 Oct 29 2003 /lib@ -> /usr/lib

These are "transition" links (hint, hint) and may not be installed in future versions of HP-UX.

[Sundar_7]

============================================2>&1 >/dev/null says: take whatever stdin (descriptor #1) is and set stdout to the same fd. Then >/dev/null changes stdout to /dev/null but stderr is still going to whatever stderr was in the beginning
============================================

With all due respect, I believe Bill intended to say this :-)

============================================
2>&1 >/dev/null says: take whatever stdout (descriptor #1) is and set stderr to the same fd.Then >/dev/null changes stdout to /dev/null but stderr is still going to whatever stdout was in the beginning
============================================

[Bill Hassell]

Thanks Sundar. Redirection based on redirection really needs some arrows and drawings. ;-}

[Robert True]

Thanks for all the comments, esp. the hints on redirection, but the tar command uses fd3 to output the list of files and because of the nesting of the shell scripts being used, I have not been able to trap it yet. I am Closing the thread as you ave gotten me on the right track, and I do not currently have time to work on it further.

Thanks again!

Rt.

[Robert True]

See my last posting.

Rt.