[Laszlo-dev] Need bash expertise: nightly-go.sh exiting prematurely

[Donald Anderson]

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: dda at ddanderson.com
>> www: http://www.ddanderson.com
>>
>>
>>
>


--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-547-7881
email: dda at ddanderson.com
www: http://www.ddanderson.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080715/78f457a9/attachment.html