Some things are just easier to do with a bourne shell. This appears to be an either/or situation where it doesn't matter if you use perl or bourne. ;-)
Regarding the test environment... If your test boxes don't change very much, you could just source an environment file with the appropriate #ifdefs to point to the correct binaries, directories, libs, etc. Once the environment variables are set up, you should be able to create any symbolic links you need.
Unless you're testing the extraction/build part of your application(s), I would recommend to extract a development or testing release from a version control system (e.g. subversion, clearcase) and perform the tests. That way, you can either correct any issues you find on the test box and check it back into the vcs or you can fix it on your development box, submit the fix to your vcs and extract the new code to your test box. Rinse, lather, repeat ;-)
You could automate the vcs extraction and testing rather easily (GUI testing is difficult to automate) by putting the process in cron or equivalent scheduler. I know of several big software firms that perform a variation of this.
Jason L. Froebe
Help find a cure for breast cancer! Net proceeds benefit the Susan G. Komen Breast Cancer Foundation and the National Philanthropic Trust. Help by donating - I'm walking 60 miles in 3 days in August 2007. (The day I return from TechWave is the first day of the Walk).
In reply to Re^3: proving something other than perl
by jfroebe
in thread proving something other than perl
by Tanktalus
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |