"goto" like command in UNIX

Hi,

 
echo "yes or no?"
read ans
 
case $ans in
 
[yY]*)
echo "yes"
;;
 
[nN]*)
echo "no"
;;
 
*)
echo "yes or no only"
#here, if the answer is not "Y" or "N", I want to go back to asking "yes or no?"
;;
esac
 

Thank you.

while [ 1 ]
do
    echo "yes or no?"
    read ans
    case $ans in
    [yY]es)
        echo "yes"
        # more statements
        break
        ;;
         
    [nN]o)
        echo "no"
        # more statements
        break
        ;;
    *)
        echo "yes or no only"
        ;;
    esac
done
2 Likes

Shell scripting has no concept of GOTO.

Try using functions for your "yes/no" results and run your "case" routine inside a "while"
loop remembering to call you functions...
Example:-

yes()
{
        echo "Do something."
}
no()
{
        echo "Do something else."
}
while true
do
        # Your case code, remembering to call "yes" or "no" as commands...
        # Remember also to give yourself a getout clause...
done

Off to work...

1 Like

Perhaps a little background could be useful Goto considered harmful (Edsger Dijkstra)

1 Like

For endless loops consider

while :

rather than

while [ 1 ]

Saves you 4 keystrokes (and a couple of CPU cycles with each iteration).

Sure it does. The break and continue statements are limited gotos. And are always translated to jumps in assembly language.

1 Like

GOTO style statements are a bad idea. Try to work out the functions of your process. I learnt this on Sinclair BASIC of all things. Using GOTO is easy to understand and GOSUB seemed excessive.

Eventually I was enlightened at school. The overall target of your code should be to perform a process. That process was split into major components, and if necessary a selection made as to which parts actually ran. For each of these major parts, we repeated the approach, and again until we could not refine it further. Each leg/relationship was either a loop, a condition or a single sequence.

Effectively coding up the lowest level respective the relationships would build your application. GOTO was not a recommended even then. We had to make subroutine and then manage the flow. Drawing up a flowchart type design with all sorts of branches quickly becomes unworkable and is a nightmare to decipher, let alone alter, evidenced by plenty of our COBOL code and C-shell scripts that I've had to extract us from in the past.

We have more ksh scripts to pick apart soon with all sorts of mad things like:-

while true
do
  some-process........
  if it worked
  then
     break        # End the while true loop
  fi
  another-process......
  if it worked
  then
     continue     # Re-start while true loop
  fi
  echo "Failed both things"
done              # Back to while true loop

echo "Finished"

It's just a mess when you end up with a script running to over 500 lines with one main while true loop and a huge case statement to have sections that should or shouldn't run.

Using functions helps organise your thoughts to build more structured code making it easier to understand later (when the documentation is usually long gone)

I have a long project to dismantle it all to more easily maintained code as we move the application to a replacement server. Deep joy fills me soul with the prospect. :eek:

Robin

Any kind of branching statement can be considered as, and implemented as, a limited goto. Which doesn't mean they're all the same thing.

Ahhh, but the concept of GOTO a line number and/or label is alien to the shell.

Joke code that works, ;o)
(Note the smiley.)

#!/bin/sh
# goto
goto() { eval $1 ; }
label1() { echo "Test line 1." ; }
label2() { echo "Test line 2." ; }
label3() { echo "Test line 3." ; }
goto label1
goto label2
goto label3
goto label1
goto label2
goto label3

I know, I know, it is dreadful coding...
Results in CygWin:-

AMIGA:~> goto.sh
Test line 1.
Test line 2.
Test line 3.
Test line 1.
Test line 2.
Test line 3.
AMIGA:~> _

I tend to stay away from functions unless they will be called more than once. I have the misfortune of trying to clean up after people who were "function happy" to the point that there are more functions than lines calling them with the called only running once.

1 Like