Re: leading null characters produced in script...

On 30 Oct 2006 08:17:01 -0800, Avalon1178 staggered into the Black Sun
and said:
I think you need 'cp /dev/null $logFile' instead of 'cat'.
Nope, that does not work. Neither does 'echo "" > $logFile".

The problem is not with the log rotation script AFAICT.

logSize=$(stat -c%s $logFile);
if [ $logSize -ge 5000 ]; then
cp $logFile $logFile.arch
cat /dev/null >$logFile

The standard convention in shell scripting is to have your variables in
uppercase. It's kind of hard to read when you try to use Pascal/Java
conventions in a bash script.

The problem is, when $logFile is written by this other script the
second time, a bunch of leading nulls are created

Here is how the other script is generating the $logFile:
./otherScript >$logFile 2>&1 &

So, if otherscript.sh has $LOGFILE open while logrotate.sh runs, what do
you think will happen? logrotate.sh runs, and it truncates $LOGFILE,
making it 0 bytes. The FILE* otherscript.sh is using does not change
when the file is truncated. Its offset position stays the same as it
was, so if it was at 5000 when the file was truncated, it'll remain
there. Then the next time otherscript.sh writes to the file, it'll
write starting at 5000. It'll be as if you did an fseek(OFP, 5000,
SEEK_SET) before writing stuff, and that's where the 0x00s are coming
from.

If you've got to rotate logs this way, the easiest thing for
otherscript.sh to do is to not keep the file open. Every time you need
to write stuff, fopen() or whatever in append mode, fprintf() or
whatever, and fclose(). This will make log rotation work better. I
can't tell you exactly how to do this without seeing otherscript.sh's
code. You'd probably have to use positional parameters in bash and
echo/write stuff >> $1 instead of stdout/stderr.

--
I will rule you all with my iron fist. YOU! Obey the fist!
--Invader Zim
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
.

Relevant Pages