«while :» vs. «while true» [duplicate]
: [arguments] No effect; the command does nothing beyond expanding arguments and performing any specified redirections. A zero exit code is returned.
As this returns always zero therefore is is similar to be used as true
The colon is a built-in command that does nothing, but returns 0 (success). Thus, it’s shorter (and faster) than calling an actual command to do the same thing.
It’s true. i=0; time while true; do ((i++>100000)) && break; done takes slightly longer than the colon version.
The difference has nothing to do with commands vs builtins, as they’re both builtin. It’s purely the additional number of characters bash is dealing with. while : some gibberish , still just using : , is slower than true . Compare this to an external command, like while /bin/true , which is literally a hundred times slower.
I found this question after a red herring due to differences between while true and while 1 — it turns out 1 is aliased to cd — which was obviously passing but printing ~ (my cwd at the time.) One caveat with : I noticed after trying this out: the usual rules apply to : , so you need to end it with a semicolon (or a line break in cases like this one, where you have an unclosed block.) So, for a one-liner, you would write while :; do . ; done as opposed to while :\n do . \n done . Really this is hardly a caveat.
@thatotherguy, almost all of my in-depth knowledge is about compiled languages — does the interpreter really re-parse everything as if it were seeing it for the first time? I would have thought that at the very least, aliases like : would be replaced the first time it was encountered. Is the anticipated scenario something like an alias or path changing in the middle of execution? I would have expected while $(echo true) . to defer but never while /bin/true — if /bin/true were found to be missing, it would fail without the need for reinterpretation.
How to run bash script while it returns code 0?
I have bash script with many lines of code and I need run it while it returns $? == 0, but in case if it has error I need stop it and exit with code 1? The question is how to do it? I tried to use set -e command, but Jenkins does not marks build as failed, for him it looks like Success I also need to get the Error message to show it in my Jenkins log I managed to get error code(in my case it will be 126), but how to get error message?
main file fileWithError.sh rc=$?; if [[ $rc != 0 ]]; then echo "exit "; fi fileWithError.sh #!/bin/sh set -e echo "Test" agjfsjgfshgd echo "Test2" echo "Test3" Your question is unclear. Is it «long» because the script itself is many lines of code, or does it run for a «long» time? Do you want it to terminate with a non-zero status if any command fails, or do you want to run it in a continuous loop, aborting only when an invocation of the script fails? What do you mean by «it has an error»? Do you mean that it encounters unexpected input? Or that one of the commands it calls exits with a non-zero status? Or that it produces output that is outside of some expected range? Clarify the question.
You still haven’t answered the many clarifying questions. set -e should indeed fail with an error so it sounds like the code which calls yours script is wrong.
I may be wrong, but it looks like you’re calling a script from another script. Jenkins only sees that you called the secondary script successfully, which technically has an exit code of zero.
3 Answers 3
Just add the command set -e to the beginning of the file
This should look something similar to this
I’ve tried the same but with #!/bin/bash, it stops my script but for Jenkins build looks like Success
Maybe try wrapping it in a script that does something that Jenkins treats as an error if the actual script fails #!/bin/sh bash actual-script.sh e=$? if [ $e -ne 0 ]; then echo «FAILED with error code $e» #do sth that looks like an error to jenkins #. #exit with error exit 2 fi
#!/bin/sh while fileWithError.sh; do sleep 1; done echo fileWithError.sh failed!! >&2 Note that if the script is written well, then the echo is redundant as fileWithError.sh should have written a decent error message already. Also, the sleep may not be needed, but is useful to prevent a fast loop if the script succeeds quickly.
You can get the explicit return value, but it requires a bit of refactoring.
#!/bin/sh true while test $? = 0; do fileWithError.sh; done echo fileWithError.sh failed with status $. >&2 since the return value of the while script will be the return value of sleep in the first construction.
Its not quite easy to get an error code only. How about this .
#!/bin/bash Msg=$(fileWithError.sh 2>&1) # redirect all error messages to stdout if [ "$?" -ne 0 ] # Not Equal then echo "$Msg" exit 1 fi exit 0 You catch all messages created by fileWithError.sh and if the programm returned an error code then you have the error message already saved in a variable.
But this will make a disadvantage, because you will temporary store all messages created by fileWithError.sh till the error appears.
You can filter the error message with echo «$Msg» |tail -n 1 , but its not 100% save.
You should also do some changes in fileWithError.sh .
Switch set -e with trap «exit 1» ERR . this will close the script on errors.
What does «while :;» mean?
Where the statement after while has to be either TRUE or FALSE . There is a shell builtin command named : . It is described as a dummy command doing nothing, but I do not know if it is the same here, even if can it be TRUE or FALSE . Maybe it is something different, but what?
The command : does nothing but always exits with return code 0. So, it is the same was while true (assuming your system has a true executable).
@John1024 It returns zero unless the evaluation of its arguments causes an error by, for example, assigning a value to a readonly variable.
@Kusalananda Yes, if the : command is never executed, it won’t return 0. That’s overly pedantic in my opinion though.
3 Answers 3
while first list of commands do second list of commands done which runs the second list of commands in a loop as long as the first list of commands (so the last run in that list) is successful.
In that first list of commands, you can use the [ command to do various kinds of tests, or you can use the : null command that does nothing and returns success, or any other command.
Runs cmd over and over forever as : always returns success. That’s the forever loop. You could use the true command instead to make it more legible:
People used to prefer : as : was always builtin while true was not (a long time ago; most shells have true builtin nowadays)¹.
Other variants you might see:
Above, we’re calling the [ command to test whether the «1» string is non-empty (so always true as well)
Using the Korn/bash/zsh ((. )) syntax to mimic the while(1) < . ; >of C.
Or more convoluted ones like until false; do cmd; done , until ! true .
Those are sometimes aliased like:
So you can do something like:
Few people realise that the condition is a list of commands. For instance, you see people writing:
while :; do cmd1 cmd2 || break cmd3 done When they could have written:
while cmd1 cmd2 do cmd3 done It does make sense for it to be a list as you often want to do things like while cmd1 && cmd2; do. ; done which are command lists as well.
In any case, note that [ is a command like any other (though it’s built-in in modern Bourne-like shells), it doesn’t have to be used solely in the if / while / until condition lists, and those condition lists don’t have to use that command more than any other command.
¹ : is also shorter and accepts arguments (which it ignores). While the behaviour of true or false is unspecified if you pass it any argument. So one may do for instance:
while : you wait; do something done until false is true; do something done is unspecified (though it would work in most shell/ false implementations).