If this was Linux, you could also use a
gdb trick. But it turns out we can rule out that trick on OS X, because it relies on Linux-specific behaviour of
That's all I know, I don't have a positive suggestion.
It could go horribly horribly wrong, but have you considered
gdb? Two miracles in one package: a C interpreter, and a way to inject code into the process of your choice! Apparently you can also use it for debugging.
Fortunately the C standard library also includes a function which interprets scripts. The scripting language on your platform might be more convenient to write than C...
I thought of a script which uses
less for OS X. This is a fragile hack to seek back to the start of the logfile based on OS X, bash: less works on open file descriptors, cat doesn't After reading the whole log file with
less, the FD position should be at the end of the file, which is hopefully the original position before we meddled with it.
<EDIT>But it only works if the file was also opened for reading. According to your
lsof output, the file was only open for writing.</EDIT>
gdb -p 264 <<EOF
call (int) system("exec </dev/null >/tmp/log 2>&1; less /dev/fd/20")
I cast the return type, because otherwise my system complained that it did not know the return type of
system(). Presumably this also means that it wasn't sure of the argument types either, so this is already sounding like such a great idea.
system() to manipulate file descriptors somehow worked when I tried it on my Linux box... once. I don't promise it will always work :). E.g., technically this is not guaranteed to be safe if the program is executing a signal handler, or indeed
system() itself. (
system() is not one of the few functions which is guaranteed to be "re-entrant").