I submitted a code on codeforces and on the 11th test case i got this-
Test: #11, time: 2000 ms., memory: 0 KB, exit code: -1, checker exit code: 0, verdict: TIME_LIMIT_EXCEEDED
Input
999999994 108004280
What does exit code: -1 signify here?
Seems like you should pay more attention to verdict: TIME_LIMIT_EXCEEDED, which means that your program did not fail but worked too long.
I suppose this exit code is just some default value for time limit exceeded cases and not something related to your code.
Related
This question already has answers here:
why shell uses 0 as success?
(2 answers)
Closed 1 year ago.
Logic expressions seem to evaluate in a backwards manner in Bash as opposed to a programming language like C.
For example, echo will return 0 upon success so I would expect:
echo hi || echo back4more
would print hi and then back4more to stdout since 0 is returned first and the second statement needs to be checked to determine the truth of the whole logical OR expression. However, it only prints hi.
Similarly, this can be seen from:
echo hi && echo back4more
Which I would expect to print hi and that's it since echo first returns 0 and thus 0 && (logic) would always be false, so no need to evaluate (logic). But what really happens is hi and back4more get printed.
Why is this so?
Success is not truth.
Zero exit status means success. Non-zero exit status means failure.
Zero arithmetic value is logically boolean false. Non-zero arithmetic value is logically boolean true.
Why is this so?
The || checks for failure. Because echo exits with 0 exit status, it means success, the right side of || is not executed.
I know that echo $? returns the exit status of the previous process.
In my program I get 0 if my program ends with a status code of 0. But when the program ends with status code -1 echo $? shows 255. Similar questions are there on StackOverflow, but is not explained why is it so. Plus one of the answers says generally values above 128 indicates some error and negative exit code. Like for example, 147 - we can get the real exit code by subtracting 128 from 147, 128 - 147 = -19, so the exit code was -19.
In my computer I find 256 as that number. For example 255 - 256 = -1, which was what my program was returning.
Why on different systems do these numbers vary 128, 256 and why can't they print the original negative code instead of adding these numbers to the original exit status code.
For historical reasons, exit code is interpreted as unsigned one-byte value. "Normal" error codes are positive (<127), while "abnormal" error codes (e.g. those produced by terminating on signal) are negative (>=128).
Try pressing Ctrl-C on a sleep 10 command. The exit code is 130.
127 is the result of "command not found".
It's really not a recommended practice to use negative error codes explicitly.
For more information, take a look at wait() man page (man 2 wait), in particular WFEXITED() and friends.
WEXITSTATUS(status)
returns the exit status of the child. This consists of the least significant 8 bits of the status argument that the
child specified in a call to exit(3) or _exit(2) or as the argument for a return statement in main(). This macro should
only be employed if WIFEXITED returned true.
(Emphasis added)
I have a script that requires at least one argument. If the arguments are incorrect I will obviously return a non-zero exit code.
I have decided to print the usage instructions when called with no arguments, but I'm uncertain of the exit code. Should it be
0 (success)
one of the values [1-125] (error)
An argument could be made either way. Is some option recommended?
It depends on whether you want the callers of your script to know programatically why it failed.
If, for example, it will only ever be run by a human, you could just return 1 and rely on the error text to inform them.
You could even return zero regardless if you only ever want a human to easily know (via the output) if it failed but I would consider this very bad form - Microsoft have made this mistake in the past with some of their commands not setting %errorlevel%, making it very difficult for a script to figure out whether it's worked or not.
Even if you decide not to indicate why it failed, you should at least indicate that it failed.
If you want a program to easily figure out why it failed, return a different code for each discernible error type.
Any Unix command when it returns control to its parent process returns a code, number between 0 and 255.
Success is traditionally represented with exit 0; failure is normally indicated with a non-zero exit-code. This value can indicate different reasons for failure.
So what you have also is another case of unsuccessful completion of your program which should be treated as returning a proper error code and not 0.
Also note that traditional Unix system calls don't signal an error code for empty arguments, they have to be caught explicitly. There are ones for argument list too long (E2BIG) and invalid arguments (EINVAL).
This is what I decided on using, based mostly on Inians answer and the reserved exit codes presented here.
I decided on somewhat reusing the exit codes defined in /usr/include/asm-generic/errno-base.h1. There was nothing suitable for "too little arguments", so I picked the first one from the 64-113 range.
# Error codes
E2BIG=7
EINVAL=22
E2SMALL=64
NAME="my-script"
USAGE=$(cat << END
the help text
RETURN CODES
$NAME has the following return codes:
0 success
$E2BIG Argument list too long
$EINVAL Invalid argument
$E2SMALL Argument list too short
END
)
# This script requires exactly one argument. If less are provided it prints
# the USAGE instructions
if [ ${#} -lt 1 ] ; then
printf '%s\n' "${USAGE}"
exit $E2SMALL
fi
if [ "${1}" = "-h" ] || [ "${1}" = "--help" ] ; then
printf '%s\n' "${USAGE}"
exit 0
fi
if [ ${#} -gt 1 ] ; then
printf '%s\n' "${USAGE}"
exit $E2BIG
fi
It's a bit verbose, but at least there's a properly defined error code if the script is called improperly.
1 This may be debatable, but since the codes were already defined...
I am curious about the logic behind && in continuous commands execution in shell.
Lets see an example: command_a && command_b && command_c
In shell, this means that once a command fails, the consequent commands will not execute and the chain should stop.
If we replace each command by its exit code, the chain becomes, for example this expression 0 && 1 && 0. (command_a succeed, command_b failed, command_c succeed)
If we try evaluating this expression, the evaluation should stop right after the first command, 0 value.
If && logic is replaced by ||, the expression would be more fit to the meaning of original chained command.
0 || 1 || 0.
Expression's evaluation stops after command_b execution
There's a difference between the semantics of a successful command and the representation of success via the numeric value of the exit code. If you consider the abstract "is a command successful", && makes more sense, since the "success" abstract boolean is true. That's why && is used. You need A to run, AND you need B to run.
But, due to the fact that there's usually only one status for success, but many different types of errors, the value 0 has been defined long ago to be used for exit status to indicate success.
So, the exit status of a command can simply not replace the command itself in such an expression. The semantics and the representation are just different.
Check out this post.
"The right side of && will only be evaluated if the exit status of the left side is zero. || is the opposite: it will evaluate the right side only if the left side exit status is nonzero..."
$ false && echo howdy!
$ true && echo howdy!
howdy!
$ true || echo howdy!
$ false || echo howdy!
howdy!
I have seen || used in some shell script too. I think it depends on the occasions. You may use command-a && command-b when you want command-b to be executed only after command-a success.
Likewise, you may use command-a || command-b to deal with the situation when command-a fails.
Update: After reading your question three times I now understand what puzzles you: That 0 represents success, and/or (sic) that logical operators treat it as true. Yes, that can be confusing, coming from C. The other Peter's answer explains that well. I let my original answer stand anyway because it is not "wrong".
It is what logic dictates if commands are impossible to perform or don't make sense unless their predecessors succeeded. That happens quite often: "Retrieve a HTML document from the web, verify the time stamp, parse a value out of it, and write that value as an updated data somewhere." Each step depends on the success of all preceding steps.
If, instead, you have something "retrieve a document from the web, or from the cache, or from disk, or take a default here document, in this order of preference", then the appropriate way to write that is indeed with logical ORs. This happens but is less common.
ORing is a common idiom though for error handling, because subsequent commands are exactly performed if the pervious failed. Consider Perl's idiomatic cmd() || die();. (You have more lives. Phew.)
I have this piece in which the variable TESTS_SUCEEDED disappears or its value is unset. I saw many examples in which variables disappear due to subshell starting in loops, but couldn't find any clue about this behaviour.
${SRCDIR}/3rdParty/bin/alxdatabasemanager
--create-database-with-name=TestAlexandriaDB || exit 1
Src/Tests/Functional/FunctionalTestLibalexandria
TESTS_SUCCEEDED="$?"
#Here variable exists
echo ${TESTS_SUCEEDED}
${SRCDIR}/3rdParty/bin/alxdatabasemanager
--delete-database-with-name=TestAlexandriaDB || exit 1
#FIXME: Variable nonexisten here or value lost??!! Why?
exit ${TESTS_SUCCEDED}
Could anyone tell me what is going on? Thanks in advance.
You are having spelling issues: TESTS_SUCCEEDED and TESTS_SUCEEDED are not the same thing.
Let's line'em up, to clarify:
TESTS_SUCCEEDED
TESTS_SUCEEDED