Just the way Scott has pointed out to you - it is one of the "correct" ways to solve that problem.

Something you might think about is to "structure" your program differently, but this has nothing to do with actual code. It is a way of looking at how programs (scripts) do what they should do and is basically a "philosophical" topic: the general UNIX program (again - any program, be it written in shell or any other language) is designed to work inside of a pipeline:

Code:

program1 | program2 | program3 | ....

For this to work a program needs to have some defined input (a file, a stream, ...) and a defined output. Picture it like a garden hose: you pour something in on top and something (else) runs out at the bottom. This "something else" then serves as the input stream for the next program until you finally get what you want out of the last one.

In order to work like this you need to avoid interactive input in any way. When you rely on interactive input you are limiting the possible usage of your program to a situation where a human sits at a screen and types something in (or provides input in another form, like clicking with a mouse). The program working in a pipeline will not be limited to this situation because it can be started and run automatically without any human intervention.

This is not to say that you don't need any interactive programs: it just means you should carefully think about which category your program - really - needs to be in. You should write programs that need manual intervention only if there is no other way at all. If it is possible to do it automatically you should do so, even if it means more work: you do this work only once whereas you do manual intervention every time the program runs.

This (and more) is discussed in a book i can heartily recommend: Advanced Programming in the UNIX Environment by W. Richard Stevens. One of the best books ever written about programming.
I hope this helps.

bakunin