> Given that ksh offers no reliable process monitoring, no programmatic > access to job status (short of parsing `jobs`), and no clean way to > block on job state change, I humbly submit that this kind of thing is > better written in a different language. :-)
I have a very nice workcrews package written in Lua that I could sell you :-) In extremis I have resorted to piping shell commands to it. The shell is just so very *good* at redirecting stdin, stdout, and stderr, and it makes it so easy to run tests on student code. E.g., did the compiler write anything to stderr? Then it's straight to the dustbin and on to the next student... It looks to me as if the best solution is probably to write the test scripts using nmake (or mk) with ksh in the action blocks (resp. recipes). I just revisited the nmake web pages and I left with the same impression I always have---the claimed features are most alluring, yet there is a little more complexity there than I can easily wrap my head around. I always wind up falling back to Andrew Hume's mk, which to my way of thinking is the simplest and best engineered modern Make. I particularly admire Andrew's decision that mk variables are shell variables, so there's no messing around with $(funny-character). $target instead of $(<) for example. If anybody can recommend what to read to learn better about nmake, I would like to know. Anything that can eliminate autoconf and configure and that can handle recursive make well is worth learning. Norman _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
