Skip to content

Exit value not zero if successful #102

Closed
djehring opened this Issue May 8, 2011 · 16 comments

3 participants

@djehring
djehring commented May 8, 2011

The Exit value for the new build appears to be 245 if successful or 1 if not rather than zero and the values posted in the changelog, excerpt from calling shell script in Xcode build below:

#!/bin/sh

MakeDocumentation.sh

iHF iPhone Library

#

Created by David Jehring on 28/04/2011.

Copyright 2011 Black Pear Software Ltd. All rights reserved.

#KEEP_FILES command line paramenter only populated if local html directory exists
if [ -d "${HOME}/Development/Devhelp" ]; then
KEEP_FILES="--keep-intermediate-files"
else
KEEP_FILES=""
fi

PUBLISHDIR=${HOME}/Development/Devhelp/bpiHF

/usr/local/bin/appledoc \
--project-name "Black Pear iHF" \
-o "${SOURCE_ROOT}/help" \
--docset-bundle-name "Black Pear iHF" \
--merge-categories \
--verbose 3 \
--docset-feed-url http://blackpear.com/devhelp/%DOCSETATOMFILENAME \
--docset-package-url http://blackpear.com/devhelp/%DOCSETPACKAGEFILENAME \
--publish-docset \
"${KEEP_FILES}" \
--print-settings \
"${SOURCE_ROOT}/iHF/Interface/iHRDataInterface.h" \
"${SOURCE_ROOT}/iHF/Plugin Support/iHFPrescribingDelegate.h" \
"${SOURCE_ROOT}/iHF/Plugin Support/iHFPrescribingProtocol.h" \
"${SOURCE_ROOT}/iHF/Plugin Support/iHFCodeBrowsingDelegate.h" \
"${SOURCE_ROOT}/iHF/Plugin Support/iHFCodeBrowsingProtocol.h" \
"${SOURCE_ROOT}/iHF/Plugin Support/iHFCodedItemExt.h" \
"${SOURCE_ROOT}/iHF/Categories/iHRPersistableObjectExt.h"

RET=$?
if [ $RET -ne 245 ];then
echo "Apple doc failed with $RET"
exit $RET
fi

@tomaz
Owner
tomaz commented May 9, 2011

Hm, this was working here, although didn't test it in Xcode. Will give it a look.

@tomaz tomaz was assigned May 9, 2011
@beelsebob

I'm seeing the same behaviour in Xcode

@tomaz tomaz added a commit that referenced this issue May 9, 2011
@tomaz Restructured exit codes handling, attempting to tackle #102.
Exit codes are now better structured to domains and error codes. Also added a debug log statement (available with `--verbose 6` switch) at the end of the run to log the exit code as "seen" by the application.
00f64b6
@tomaz
Owner
tomaz commented May 9, 2011

Try the update and let me know if it works now. If not, try using --verbose 6 cmd line switch, it'll log the exit code just prior to returning it. Will leave the issue open until confirmed.

@beelsebob

Still exits with 245 for me, --verbose 6 does not log anything thanks to #104

@tomaz
Owner
tomaz commented May 9, 2011

Does it log something if you don't redirect?

@beelsebob

Oops, my bad, mis-pulled. Xcode reports exit with status 1 now, the binary run in a shell reports exiting with 513 (which is equal to 1 given that exit codes wrap on 256). Re redirecting – it's not possible to stop redirection in Xcode – it does it to capture the output and display it. This means the only way to debug this is to run it out of my normal environment.

@tomaz
Owner
tomaz commented May 9, 2011

513 makes sense: it's 0x201, which is due to a warning. Wasn't aware of 256-wrapping, will lower down the domain codes to make sure it stays within, hope that fixes it.

@beelsebob

Most UNIX programs would be expected to give exit 0 for warnings. Compilers will even exit 0 with an error, because while the program was erroneous the compiler was still successful in producing it's output correctly.

@tomaz
Owner
tomaz commented May 9, 2011

Yea, this could easily be configurable, like --treat-warnings-as-errors or something similar, then it's up to users to decide how strict they want to run.

@tomaz tomaz added a commit that closed this issue May 10, 2011
@tomaz Refined exit codes handling. Closes #102.
This commit concentrates on two related issues:

- It adds a new command line switch `--exit-threshold` which allows users specify the threshold value (numeric) which is used to filter out tool exit codes: if reported exit code is below the threshold value, tool simply returns 0.

- Restructures exit codes values to have higher value representing more severe condition. This plays nicer with previous point. Currently warning has value 1, error 2, fatal 3 (although fatal is not used currently in the tool).

Note that it's not possible to suppress crashes, regardless of whether the threshold is set above the value (250 currently)!

Also updated build number to 692.
ee93385
@tomaz tomaz closed this in ee93385 May 10, 2011
@tomaz
Owner
tomaz commented May 10, 2011

Let's see if this commit fixes it, feel free to reopen the issue otherwise!

@beelsebob

Now exits with exit code 1, despite success. This causes Xcode to report an error. As no error has occured in appledoc (as opposed to somewhere in the documentation) it should exit with status 0. I can't reopen the bug as it doesn't belong to me.

@tomaz tomaz reopened this May 10, 2011
@tomaz
Owner
tomaz commented May 10, 2011

Hm, that's weird, exit codes should now be: 0 success, 1 warnings reported, 2 errors reported, 3 fatals reported, 240 crash. They are all below 256, so there should be no wrapping. Oh, and it properly returns 0 for me (when run directly), obviously Xcode still thinks the tool failed. This can be due to redirected stdout/err, so I'll have to check what DDTTYLogger does internally.

@beelsebob

1,2 and 3 should all be 0. The error is not in appledoc, it's in it's input, thus appledoc didn't fail.

@tomaz
Owner
tomaz commented May 10, 2011

Have you tried newly introduced --exit-threshold <value> cmd line switch? The value specifies the threshold above which appledoc should report non-zero exit. Will update online docs shortly, but until then just use --exit-threshold 4 which will effectively return 0 when either of the three would otherwise be returned.

@beelsebob

Perfect. Now just to get those logs working through a redirect and it'll work perfectly in Xcode :)

@tomaz
Owner
tomaz commented May 10, 2011

Great, closing the issue therefore, logging will be handled shortly with #104.

@tomaz tomaz closed this May 10, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.