Return to Answer

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, such as Ant or Make; other tools are available and recommended by Torben, that might also be suitable.

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, such as Ant or Make; other tools are available and recommended by Torben which might also be suitable.

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, such as Ant or Make.

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, such as Ant or Make; other tools are available and recommended by Torben, that might also be suitable.

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, namely Make.

No #! line to specify interpreter. Perhaps not so important for something that's portable shell, but still helpful to write #!/bin/sh.

No checking that cd was successful. We really don't want to continue if that fails for any reason. Similarly if javac fails, we want to exit with non-zero status. We could add || exit after all commands, but it's easier and simpler to begin the script with set -e.

I'm guessing the redirection of rm's standard error is to cope with Project.jar not existing. I suggest using rm -f instead, which is silent in that case (but will remove read-only files, assuming the directory is writable).

Using shell might work for the short term, but as your project grows, you'll find that going through all the steps unconditionally becomes more and more time-consuming. That's the point to move to a tool that's designed for resolving dependencies and orchestrating builds, such as Ant or Make.