On Jul 30, 2008, at 1:15 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote:> I've been thinking of constructing a mirror test suite coordinated > using > shell scripts (bash)Please no, pick a real language. I love bash and it is fine for any 200 line or less program, but for much beyond that, something else. Python?c? C++?
Mike Stump wrote:> On Jul 30, 2008, at 1:15 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > >> I've been thinking of constructing a mirror test suite coordinated >> using >> shell scripts (bash) >> > > Please no, pick a real language. I love bash and it is fine for any > 200 line or less program, but for much beyond that, something else. > Python?c? C++? >If I thought C was an appropriate choice to get this done, I'd be patching the expect source code instead to deal with Microsoft's non-implementation of POSIX. If a language conceals the differences between POSIX and Microsoftian C for interprocess control, hides badly non-POSIX filepaths from me, and has a reasonable track record of forward compatibility, and has a reasonably universal build process, I'll consider crash-learning the language if I'm not already working in it. [I do some programming in Python already. Python lost out because it hasn't been forward-compatible on my in-house projects; broken non-deprecated features have forced maintenance on the 2.2 |-> 2.3, 2.3 |-> 2.4, and 2.4 |-> 2.5 version jumps. Annoying; the subprocess module is an ideal match.] Kenneth
Kenneth Boyd <zaimoni at zaimoni.com> writes:>>> I've been thinking of constructing a mirror test suite coordinated >>> using shell scripts (bash) >> >> Please no, pick a real language. I love bash and it is fine for any >> 200 line or less program, but for much beyond that, something else. >> Python?c? C++? >> > If I thought C was an appropriate choice to get this done, I'd be > patching the expect source code instead to deal with Microsoft's > non-implementation of POSIX. > > If a language conceals the differences between POSIX and Microsoftian C > for interprocess control, hides badly non-POSIX filepaths from me, and > has a reasonable track record of forward compatibility, and has a > reasonably universal build process, I'll consider crash-learning the > language if I'm not already working in it.For my test suite I use Tcl (with TclX, no Expect). It watches stdout and stderr, gets exit codes and has a timer for killing hanged processes. Process control works the same on Windows and Unix and takes a less than 30 lines of code. What else do you need? -- Oscar