>>>>> "Brian" == briand <firstname.lastname@example.org> writes:
Brian> This is a little long, but trust me, it's worth it.
Brian> Maybe this is revision 0.6.6.6 ?
No, I just checked, it's 0.8.15 ;-)
Brian> Look at this snippet of code :
Brian> That's right, the program exits prematurely. And all I did was change
Brian> the 0 to a string... It works if it is a number, it works if it is a
Brian> symbol, it works if it is a list, it works if it is a vector, but if I
Brian> change it to a string the program quits before it even gets to that
Brian> point. In fact, if I do something like (car (list "string")) it still
Brian> breaks, but (car (list 0)) works.
Brian> And a string constant at that. So there is NO WAY that the program
Brian> can be failing above that point if it doesn't fail for all of the
Brian> other variable types.
Maybe it takes a different path of evaluation if the fourth field is a
Brian> And yes, there are 4 slots in the exec-results record.
Brian> scsh hates me.
I don't think so, but I understand your frustration.
Brian> P.S. No I can't produce this by itself. It only does this as part of
Brian> the script I am running. So if I take the exec-results record and
Brian> isolate it in a test, it works every time.
Could you mail me the whole script?
Brian> P.P.S. I think the program run, I think there is something strange
Brian> going on with buffering of the output, and something is failing and
Brian> the output hasn't been flushed yet. But how in the heck am I going to
Brian> figure out what !
This indeed looks as if scsh would not print all it knows. The CVS
version of scsh contains a few bugfixes for port flushing, but I don't
think they matter in your case, but before you begin to hate
scsh, you could give it a try...
Alternatively, wrap a handler around the program and display the
condition to the current error port:
(lambda (cond more)
(display cond (current-error-port))