Searching for something else, came across this little gem:goto in bash

goto in bash
October 26, 2012hackingbash, basic-hate

If you are as old and nerdy as I, you may have spent your grade school days hacking in the BASIC computer language. One of the (mostly hated) features of the (mostly hated) language was that any statement required a line number; this provided both the ability to edit individual lines of the program without a screen editor, as well as de facto labels for the (mostly hated) GOTO and GOSUB commands. But you could also use line numbers to run your program starting from any random point: “RUN 250″ might start in the middle of a program, typically after line 250 exited with some syntax error and was subsequently fixed.

Today, in bash, we have no such facility. Why on earth would anyone want it, with the presence of actual flow control constructs? Who knows, but asking Google about “bash goto” shows that I am not the first.

For my part, at $work, I have a particular script which takes several days to run, each part of which may take many hours, and, due to moon phases, may fail haphazardly. If a command fails, the state up to that point is preserved, so I just need to continue where that left off. Each major part of the job is already factored into individual scripts, so I could cut-and-paste commands from the failure point onward, but I’m lazy.

Thus, I present bash goto. It runs sed on itself to strip out any parts of the script that shouldn’t run, and then evals it all. Prepare to cringe.

Trust me, crappy code can be written using structured programming just like efficient well written code could be written using gotos. The language isn't what makes a program sloppy or inefficient, the programmer is.

Yes, I know programming style is a matter of BCAK and thus you can produce spaghetti code with structured programing as well as using goto's and in fact pretty old assembly code could be a great example of efficient well written code... but there's a key difference, pretty old assembler has RET statement while DOS scripting (aka BAT files) does not and that's the key point about language contrbuting to crappy code, let's see in in you own example

It's seems pretty clear and clean at first sight but what if you need to call a subroutine inside your rutine? crappiness appeared!

#!/usr/bin/env bash
source /path/to/basic.inc
# The two lines above now the only non-Basic lines.
print "hello just testing the new print command"
rem this is just a comment, does nothing
sleep 2 # same as in Basic
cls

It's there more for historical reasons. The colon builtin : is exactly equivalent to true. It's traditional to use true when the return value is important, for example in an infinite loop:

while true; do
echo 'Going on forever'
done

It's traditional to use : when the shell syntax requires a command but you have nothing to do.

while keep_waiting; do
: # busy-wait
done

with what someone added:

Because : is a command, the shell still has to process its arguments before it can discover that : ignores them. Mostly, you are just making the shell do extra work in expanding * to a list of files in the current directory; it won't actually affect how the script works. – chepner Nov 5 '14 at 14:48

I suppose it might make your script fail if you happen to run in in a directory with a lot of files, making the glob expansion go over the command length limit? Maybe only if you have set -e on. Anyway, hopefully we can all just agree to use # – Jack O'Connor Nov 7 '15 at 22:14

So, in short, nope, ":" is not a comment!
It is a "program" that ignores all parameters, but like the comments above, using "* * *" could make a script crash. xD

But.... using "#" instead of ":" would not work, cause for bash "#" is like ""