Windows XP Embedded SP2 Feature Pack 2007, due to be released on Nov. 1st, will include a redesigned command-line scripting tool. This whitepaper introduces the new tool and gives a few examples of what it can do. XPECMD, as it’s called, is said to be a major upgrade to CMI Explorer, the tool that shipped with XPe SP1.
looks like windows will soon have more CLI shells than Unix…
Why can’t they just strip monad or whatever ?
Unix has several shells, but at least the defaults are almost compatible with eath others (including ash/busybox for embeded IIRC).
What strikes me is MS is trying to fit windows into stuff where it might not be suitable (one-fits-all), yet designing separate implementations of stuff that could actually be common across platforms. There is probably an extraneous “not” opcode in someone’s brain at Redmond
Will the shell be able to make use of “long file names” or will it work with “ye olde DOS” 8.3 filenames like PROGRA~1 or MICROS~1 as seen in “Windows XP”?
XPECMD supports both 8.3 and long filenames. For example, both of these commands are valid (provided the paths exist in your file system):
(EDIT: Due to limitations of this messageboard, each occurrence of “\\” should be a single backslash. I apparently can’t type a single-backslash, though – it disappears once the comment is submitted.)
BUILD myCfg “c:\\My Images\\image1”
BUILD myCfg c:\\MYIMAG~1\\IMAGE1
As with most systems (and the CMD shell itself), paths with spaces must be enclosed in double-quotes to be treated as a single argument. That’s the only major requirement.
Edited 2006-10-13 17:45
Just to clarify: XPECMD is not a shell, but rather a command-line tool that serves as a partial replacement for the GUI tools such as Target Designer and Component Database Manager. It functions in a similar manner to things like NETSH, which have very specific functions and syntax, and can be run in either an interactive or scripted mode.
Also, XPECMD is not for use within an XP Embedded runtime (hence one of the reasons we didn’t call it a shell), but rather is used at the same level as Target Designer to help design, build and deploy runtimes.
myInst.Properties(“cmiUserGroup”) = 0
hmm that looks more like javascript than a CLI… but then again maybe javascript itself as a shell would be more standard. Hey what am I thinking, MS shuns standards.
It’s actually VBScript syntax. XPECMD is primarily a build automation tool, not a separate shell, and it is written in (and based on) VBScript. It provides sort of a hybrid command syntax – it has its own built-in commands that have their own structure (including the SQE syntax), but it is also possible to issue straight VBScript commands (to a limited extent). The syntax for working with object properties and accessing subobjects (like Instance.Properties) all conforms to the VBScript standard.
However, more advanced VBScripting within XPECMD is not supported – for instance, XPECMD does not (currently) give you a mechanism to set up If/Then or For/Next loops. It is really meant to just execute linear scripts and one-shot commands, and is most useful in an automation environment where a “driver” script or program can pre-generate a Response file for XPECMD to follow.
Hope this helps in understanding how XPECMD works.