[bjam] SHELL enhancements?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[bjam] SHELL enhancements?

Rene Rivera
Once upon a time there was a request to change the SHELL builtin to be
able to get the result code of the command run. At the time I pointed
out the problem of having to return 2 values, the captured output and
the result code, which would break existing uses. This morning I had an
idea that would allow us to have the result code but still maintain
compatibility. I'm proposing we change the rule to be:

     SHELL ( command : * )

Where options would allow for specifying an "exit-status" option to also
return the wanted status. This would also allow for future expansion for
example to allow "no-output" (don't capture output just run), and
"input" (to feed strings into the command).

Thoughts?


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: [bjam] SHELL enhancements?

Doug Gregor

On Jan 27, 2006, at 1:06 PM, Rene Rivera wrote:

> Once upon a time there was a request to change the SHELL builtin to be
> able to get the result code of the command run. At the time I pointed
> out the problem of having to return 2 values, the captured output and
> the result code, which would break existing uses. This morning I  
> had an
> idea that would allow us to have the result code but still maintain
> compatibility. I'm proposing we change the rule to be:
>
>      SHELL ( command : * )
>
> Where options would allow for specifying an "exit-status" option to  
> also
> return the wanted status. This would also allow for future  
> expansion for
> example to allow "no-output" (don't capture output just run), and
> "input" (to feed strings into the command).
>
> Thoughts?

That would be great. Actually, it also gives us a place to specify  
what should be done with output that goes to standard error (now, it  
just leaks out to the terminal).

        Doug
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build