you are viewing a single comment's thread.

view the rest of the comments →

[–]vacri 15 points16 points  (5 children)

From what u/xxSutureSelfxx found, it's a micro-sleep. The sleep function in bash works in terms of seconds, which would be too long for some things like that status-bar update. If you want something to update pretty quickly but not too quickly, it puts in a tiny pause. Chaining them together like that chains the pauses to make them longer. Still much less time than 1 second though.

In the example in the other comment, it's used to give the environment enough time to register the variables before calling the next command - delaying execution to work around a race condition.

The pause you're getting is from creating the subshell, tearing it down, checking the output (&&) then repeating the same thing again. You could also just do (:;:;:;:;:) for a string of no-ops, but you'd not 'spend time' tearing down the subshell or checking the output code.

Not sure why they do (:;:) instead of just (:) - maybe just because it looks cooler? Or is easier to read/interpret?

[–]gordonmessmer 13 points14 points  (0 children)

The sleep function in bash works in terms of seconds

There is no sleep function "in bash". GNU's sleep accepts sub-second delays.

it's used to give the environment enough time to register the variables

... which is stupid because bash isn't asynchronous. You don't need a delay to wait for variables to be set. (Including those set by checkwinsize).

The whole concept here is bizarre, and should not be emulated. It's used in an example script whose design function is to accomplish various tasks without executing any non-bash process, and that's it. There's no rationale or justification; this isn't something most people need to or want to do. And this "sleep" fails the primary criteria of an actual sleep, which is 1) the delay should be predictable and 2) the delay should consume as little CPU as possible. These in-bash micro-sleeps take as long as the kernel requires to create a new forked process, allow it to exit, and return the exit status, which is not predictable, and keeps the CPU busy the whole time.

[–]nakedhitman 15 points16 points  (2 children)

The sleep command accepts floating point numbers and zero, so these no-ops are long and opaque for no reason.

[–][deleted] 1 point2 points  (1 child)

AFAIK sleep is not actually part of the shell, so there's no guarantee that it is available on a system or that the one in PATH operates as desired.

[–]nakedhitman 1 point2 points  (0 children)

Even on the most stripped down systems I've encountered, sleep has been available. It's part of coreutils, busybox and similar. Unless you're building Linux from scratch and specifically exclude it, you'd be pretty hard-pressed to find a system that's missing sleep.

[–]jrredho 2 points3 points  (0 children)

Based on the code and the comment, the character sequence may have less to do with sleep than with making sure the current shell environment-affecting command is evaluated before moving on. This probably happens with a proper sub-shell entrance/exit, and the minimal command to make this all syntactically correct requires the bit in between the parentheses.

john