Skip to main content
Unix & Linux

Return to Answer

quote variable
Source Link
dubiousjim
dubiousjim
  • 2.7k
  • 20
  • 27

The answers about looping are good ways to handle this. But for reference, there is nothing wrong with having the script re-invoke itself, thus /usr/local/bin/myscript could read:

#!/bin/sh
...
if [ yes = $answer"$answer" ]; then
  /usr/local/bin/myscript
fi

You don't need an exit 0 in the other case because that will happen automatically. Also if you know you're in the same working directory at the end of the script as you were at the beginning, then you could avoid hard-coding the path of the script by instead just using $0.

There's one last refinement that is important. As written, the script process first started will spawn a second one, and wait for it to finish; the second may then spawn a third and wait for it to finish; and so on. This consumes resources, and there really is no work for those scripts to do when their progeny exit. So you'd do better to run them using the equivalent of a "tail-call" in programming. This is done using the command exec:

#!/bin/sh
...
if [ yes = $answer"$answer" ]; then
  exec /usr/local/bin/myscript # or exec $0
fi

This works just like before, except that the first process exits as it starts the second, and when the second finishes, if it hasn't spawned a third process, we go back directly to whoever launched the first process, presumably the shell.

The answers about looping are good ways to handle this. But for reference, there is nothing wrong with having the script re-invoke itself, thus /usr/local/bin/myscript could read:

#!/bin/sh
...
if [ yes = $answer ]; then
  /usr/local/bin/myscript
fi

You don't need an exit 0 in the other case because that will happen automatically. Also if you know you're in the same working directory at the end of the script as you were at the beginning, then you could avoid hard-coding the path of the script by instead just using $0.

There's one last refinement that is important. As written, the script process first started will spawn a second one, and wait for it to finish; the second may then spawn a third and wait for it to finish; and so on. This consumes resources, and there really is no work for those scripts to do when their progeny exit. So you'd do better to run them using the equivalent of a "tail-call" in programming. This is done using the command exec:

#!/bin/sh
...
if [ yes = $answer ]; then
  exec /usr/local/bin/myscript # or exec $0
fi

This works just like before, except that the first process exits as it starts the second, and when the second finishes, if it hasn't spawned a third process, we go back directly to whoever launched the first process, presumably the shell.

The answers about looping are good ways to handle this. But for reference, there is nothing wrong with having the script re-invoke itself, thus /usr/local/bin/myscript could read:

#!/bin/sh
...
if [ yes = "$answer" ]; then
  /usr/local/bin/myscript
fi

You don't need an exit 0 in the other case because that will happen automatically. Also if you know you're in the same working directory at the end of the script as you were at the beginning, then you could avoid hard-coding the path of the script by instead just using $0.

There's one last refinement that is important. As written, the script process first started will spawn a second one, and wait for it to finish; the second may then spawn a third and wait for it to finish; and so on. This consumes resources, and there really is no work for those scripts to do when their progeny exit. So you'd do better to run them using the equivalent of a "tail-call" in programming. This is done using the command exec:

#!/bin/sh
...
if [ yes = "$answer" ]; then
  exec /usr/local/bin/myscript # or exec $0
fi

This works just like before, except that the first process exits as it starts the second, and when the second finishes, if it hasn't spawned a third process, we go back directly to whoever launched the first process, presumably the shell.

Source Link
dubiousjim
dubiousjim
  • 2.7k
  • 20
  • 27

The answers about looping are good ways to handle this. But for reference, there is nothing wrong with having the script re-invoke itself, thus /usr/local/bin/myscript could read:

#!/bin/sh
...
if [ yes = $answer ]; then
  /usr/local/bin/myscript
fi

You don't need an exit 0 in the other case because that will happen automatically. Also if you know you're in the same working directory at the end of the script as you were at the beginning, then you could avoid hard-coding the path of the script by instead just using $0.

There's one last refinement that is important. As written, the script process first started will spawn a second one, and wait for it to finish; the second may then spawn a third and wait for it to finish; and so on. This consumes resources, and there really is no work for those scripts to do when their progeny exit. So you'd do better to run them using the equivalent of a "tail-call" in programming. This is done using the command exec:

#!/bin/sh
...
if [ yes = $answer ]; then
  exec /usr/local/bin/myscript # or exec $0
fi

This works just like before, except that the first process exits as it starts the second, and when the second finishes, if it hasn't spawned a third process, we go back directly to whoever launched the first process, presumably the shell.