Hi Brad,
I have one other question regarding something you said earlier in this thread:
So what this means is that you basically can’t pipe or redirect the output of a failing command anywhere as CommandBox has been designed to just abort right there, print the error message and return to the shell. Makes sense now that I think about it.
We have an interceptor for preServerStart that adds an interface alias to the loopback adapter if you’re on a mac and the alias doesn’t already exist. (MacOs only binds 127.0.0.1 to your loopback address instead of the whole 127.0.0.x subnet like every other OS. arrrrrg!) . To detect if the alias exists, I would ping the IP address and pipe that to /dev/null and then check the exit code. If it fails, it fails silently and I know the alias needs to be added.
With commandBox 4.0.0, it sounds like this type of thing is no longer possible. When my interceptor fires and the ping command fails, it prints the stack trace to the screen, “lucee.runtime.exp.CustomTypeException: No active job”. I think this is due to the “throw()” on line 365 of interactiveJob.cfc: “throw( ‘No active job’ );”
My question is, is it no longer possible to execute an external command that fails inside of a *server interceptor? Will the improvement in commandbox 4.1 allow me to execute a command that fails? (Add setting to force “non interactive” shell that disables fancypants progress output)
thanks!
–Joel