David T. Ashley <dash...@gmail.com> writes: > We develop embedded software for 32-bit micros using Windows as the > development platform.
I'll mostly ignore the "Windows" qualifier. If you're stuck with Windows CE or similar, then ask them what they suggest. If you're developing on Windows and deploy on something else (typically, some form of linux), then, well, think again. > We are seeking a general purpose scripting language to automate > certain tasks, like cleaning out certain directories of certain types > of files in preparation for ZIP'ing, generating certain source files > automatically, etc. That's exactly what "shells" are for. They are basically command interpreters providing a nice interface to various system utilities. Busybox is a variant where utilities are actually compiled in, and where you can compile your own stuff in as well. See http://en.wikipedia.org/wiki/Busybox > a)Should be able to compile the script interpreter as a monolithic > executable (no .DLL dependencies, etc.) for easy versioning and > distribution of the script interpreter. A fairly common requirement for shells. > b)Should be extensible, in that one could add commands or library > functions to the script interpreter in C (for efficiency), and the > whole script interpreter could again consist of a single executable > with no other dependencies. It looks like busybox is able to do this (the faq is fairly precise in implementation details---I've never done this but it looks kind of trivial). > c)Should be able to spawn compilers and capture the output, do file > I/O, and all the other minor expected stuff. Trivial for any shell, and probably for any scripting language. > d)Graphical capability would be nice. That's a large can of worms. I don't know any small, self-contained interpreter that includes a full-featured GUI framework. These things usually end up in shared libs, which you explicitely want to avoid... > I know that Tcl/Tk would do all of the above, but what about Python? > Any other alternatives? Most scripting languages have evolved way beyond "scripting" tasks, and usually rely on a fairly extensive set of libraries (either shared libraries or collection of modules). I haven't looked at tcl/tk since I know python, but they can probable be classified in the same category. Of course, expect python supporters to... support python (which, btw, interfaces with tk). Another contender is lua, which has a good reputation regarding embeddability. The answer really depends on your use case. I think you will be better off if you keep the GUI aspect separated from the rest. Here is stackoverflow entry discussing the use guis for (unix) shell scripts: http://stackoverflow.com/questions/928019/how-to-make-a-gui-for-bash-scripts (via google "linux shell script gui"). -- Alain. -- http://mail.python.org/mailman/listinfo/python-list
