> What do you think about the following?:
>
> 'exit %the_code%' would be equivalent in its effect to the weird 'color 00'
> call. The side effect of using 'exit' were, that it would not run under
> Win95/98 (I can perfectly live with that) but that we can return a non zero
> exit value to Java programs calling this script (see script above). If we
> use 'exit', we might as well move from .bat to .cmd to have a more powerful
> shell language available (which can't be used for Win9x). The probably very
> tiny (or zero) numbers of Win9x users can always use cygwin to run Gradle.
>
> - Hans
Hi Hans,
If you mean this Groovy script
> String command = 'ant unknownTask'
> ByteArrayOutputStream outStream = new ByteArrayOutputStream()
> ByteArrayOutputStream errStream = new ByteArrayOutputStream()
> Process proc = ['cmd', '/c', command].execute()
> proc.consumeProcessOutput(outStream, errStream)
> proc.waitFor()
> String output = outStream
> [... etc]
yes, I used this Groovy program to test the return code passing.
Here again a summary:
exit %somecode%
pro: reliably returns the code from .cmd script to calling (Groovy) program
con: brutally ends the shell if .cmd script called from
interactive command line
exit /b %somecode%
pro: doesn't brutally end the shell if .cmd script called from
interactive cmd line
con: doesn't pass return code from .cmd script to calling program
I personally would go for both of them, using this workaround:
=========================
...
rem Set env var EXIT_WITH_CODE if you need the _script_ return code instead of
rem the _cmd.exe /c_ return code!
if not "" == "%EXIT_WITH_CODE%" exit %the_code%
exit /b %the_code%
=========================
Usage would be:
- if someone calls gradle.cmd from a Program (like you wrote in the
Groovy script above), she/he should also define the environment
variable EXIT_WITH_CODE with some non-empty value => "exit %the_code%"
gets executed, return code reliably transferred
- if someone calls gradle.cmd from interactive command line (shell),
environment variable EXIT_WITH_CODE is not defined => gradle.cmd ends
with "exit /b %the_code%", return code transferred to shell and shell
is not terminated.
This way both win: interactive users and calling programs.
Suggestion #2, which I don't like too much, is to provide two scripts.
E.g.:
gradle.cmd (ends with "exit /b thecode")
gradlerun.cmd (ends with "exit thecode")
Suggestion #3: use another java exe wrapper instead Launch4J.
E.g. JSmooth: http://jsmooth.sourceforge.net From the features list:
"You can force the executable to search in the path first, and in the
registry last, or
in JAVA_HOME first. We have all the flavours! "
http://jsmooth.sourceforge.net/docs/images/jsg-selection.png
Well, now somebody has to decide... Anybody with more suggestions/comments?
--
Victor
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
