1

I have a script that uses the exec command to redirect STDOUT and STDERR to a file. The script works fine under Solaris 9. I am testing it on Solaris 10 on VMware and it fails at the exec command.

prog=`basename $0`
log="${LOCLOG}/${prog}$$"

if test -z "$LDDEBUG"
then
    exec > ${log} 2>&1

    chmod 644 "${log}"
else
    set -x
fi

In the above, the script ends right at that line without any error message.

I added quotes around variable exec > "${log}" 2>&1. This let the script run to the end, but it did not create the log file.

I then tried it with a file path:

exec > /tmp/blahblah1 2>&1

... and it worked. It created the file and wrote to it. But this doesn't solve my problem because the log filename has to be generated in the script.

I am lost for a solution here and I know it probably is very simple, but I can't think of anything else to do without having to make any major change to the script.

====== Output of sh -x

ld-test@lunar-tst[60] sh -x /home/hameed/test/local/bin/qikload
+ basename /home/hameed/test/local/bin/qikload
prog=qikload
datefmt=+%H:%M:%S
dayfmt=+%y%m%d
log=/home/hameed/test/local/etc/log/0508/qikload2199
+ test -z
+ exec

=======

Then I removed the 2>&1 and ran sh -x and it went passed that line.

+ basename /home/hameed/test/local/bin/qikload
prog=qikload
datefmt=+%H:%M:%S
dayfmt=+%y%m%d
log=/home/hameed/test/local/etc/log/0508/qikload27213
+ test -z
+ exec
+ chmod 644 /home/hameed/test/local/etc/log/0508/qikload27213
+ date +%H:%M:%S
now=10:44:23
+ echo Log: 10:44:23 Commencing loads
Hameed
  • 2,227
  • 1
  • 21
  • 31

1 Answers1

1

One very plausible cause of the failure is that $LOCLOG is unset on Solaris 10 under VMWare (but is set on Solaris 9), so the script is trying (but failing) to write in the root directory.

You can validate this by checking that $LOCLOG is set (for example, echo LOCLOG="$LOCLOG" without any redirection).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Thanks for the reply. That was the first thing I did. It is definitely set. – Hameed May 06 '13 at 23:09
  • 1
    OK: is there anything peculiar about the value of `$LOCLOG` on Solaris 10? What is the value of `$LOCLOG` on each system? Any difference in the permissions on the `$LOCLOG` directory? Is there any danger that `$LOCLOG` is a file on Solaris 10 but a directory on Solaris 9? Which user is running this script? Any chance of an NFS-mounted file system giving user `root` grief? – Jonathan Leffler May 06 '13 at 23:22
  • None of the above. Other programs I have run have no problem accessing and writing to it. The value of LOCLOG changes daily when the user logs in: `/home/hameed/test/local/etc/log/0508` – Hameed May 07 '13 at 00:25
  • OK - and does that directory exist? Try redirecting only standard output (so standard error is still visible); what error is reported? Can you show the output of `sh -x your_script` (or the equivalent for any other shell you're using)? Which shell are you using, in fact? – Jonathan Leffler May 07 '13 at 00:27
  • I have updated the original post with output of `sh -x`. I use `sh` and I tried `bash` as well. The directory exists. There was no error reported when I removed stderr redirection. It is weird that even chmod in the next line doesn't report any error. :s – Hameed May 07 '13 at 00:57
  • Note that when you redirect standard error to the log file, you stop getting trace to the terminal — the trace is on standard error and that's going to the log file. Are we chasing a red herring by any chance? – Jonathan Leffler May 07 '13 at 01:46
  • I worked it out. It was just another bad day for me. Just another Environment Variable that was not set hence causing deletion of log file at the end of the script. Thanks for your time, Jonathan. Feeling pretty silly right about now. – Hameed May 07 '13 at 05:02
  • 1
    Stuff like that happens — let him (or her) who has never made such a mistake throw the first stone (and I'll show you a novice programmer!). – Jonathan Leffler May 07 '13 at 05:03