Oh yes, you're right. I guess the only downside with yours is if
there was another 'here' document embedded.
Or as you say, if there's a size limit (though I would think it would
allow pretty large ones).
Hmm, also in your version I don't think any variables ($foo) known to
the outside shell
get substituted.
Yet another approach that avoids a subshell and should be even
closer to the original:
set -xv
exec >> log_file 2>&1
....script body...
(lots of examples of using exec to manipulate file descriptors here:
http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/x13082.html)
On Jul 15, 2008, at 9:54 AM, P T Withington wrote:
I think what I wrote and what you wrote boil down to the same thing,
don't they? Create a subshell with verbose and expand on, send
standard and error output to a file, run ...script body... -- I
supply the script body as a 'here doc' on standard in, you are
supplying it 'in line' to the subshell. Under the covers who knows
if there is a difference.
But, since I am at a loss, I think I will try your formulation to
see if it works any better. I wonder if I am hitting some stupid
limit on the size of a here doc. Seems very un-gnu-like, but who
knows...
On 2008-07-15, at 09:38EDT, Donald Anderson wrote:
Won't the technique you're using just put the text of the script
into the log file?
(instead of executing the script).
Several ways around this, easiest might be:
(
set -xv
...script body....
) >> log_file 2>&1
On Jul 15, 2008, at 9:21 AM, P T Withington wrote:
I tried to make nightly-go log more of its output by taking the
main body of the script and executing it in a subshell like so:
sh -xv >> ...log file... 2&>1 <<'EOF'
... script body ...
EOF
The idea is that the log file will see the actual steps of the
bash script, not just the output of the ant_call. If I comment
out the step that fetches the source (just as a test), then the
script runs just fine through all the steps and I get the expected
failure message. But if I do an actual build, right after the
dist-one build finishes, the whole script just stops (even though
there are many more steps).
I'm stumped. If no one has any suggestions, I guess I will remove
this bright idea of trying to capture all the output and give up.
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-547-7881
email: [EMAIL PROTECTED]
www: http://www.ddanderson.com
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-547-7881
email: [EMAIL PROTECTED]
www: http://www.ddanderson.com
