It’s the little things…

Ever since I started working with console-based WSH scripts, I found the tendency to break input pipes if not launching explicitly with cscript to be a source of frustration and actual damage.

A few weeks ago, I started using “shadow scripts”: I would generate a CMD or BAT file with the same base name as a WSF, in the same folder, and give it the one line:

    @cscript "%~dpn0.wsf" %*

Although it was a little annoying to do at first, I found that I was suddenly writing more and more console scripts due to how simple use was. It makes calling and piping ten times easier.

Getting a schema for mssecure.xml with “infer”

[Listening to: Mozart – Fur Elise (03:34)]

While looking for a way to handle patch management mini-tasks, I ran across the following response by a Microsoft employee to a request for the schema for mssecure.xml (in context, the softie did not sound happy about having to give this kind of answer):
Microsoft doesn’t publish the schema for the MSSECURE.XML file. We reserve the right to modify, change and update the schema as necessary to enhance products that rely on and use the MSSECURE.XML file.

That’s not precisely true. Microsoft does publish a schema, an implicit one. What people tend to forget is that any well-formed XML file conforms to a schema. It may not be a formal one or even an appropriate one, but a schema can be inferred from that XML file instance.
Of course, no one wants to spend hours trying to determine a schema from a 1.7 MiB file. If you get Microsoft’s own xsdinfer tool, though, you can automatically parse the schema in seconds.

I proceeded to do that with the latest (2003-10-03) mssecure.xml and I have made the inferred mssecure.xsd file available as a zipped download.
Note that this is incredibly easy to do. I simply ran
  infer mssecure.xml -o mssecure
and had mssecure_1.xsd ready in seconds. The schema is very clean considering the size of mssecure.xml; it reduces to 11.8 KiB and compresses to 1.7 in the download.

.NET and Console Tools – We’re Getting There, But…

[Listening to: We Have Explosive – The Future Sound of London – We Have Explosive (03:26)]

I’ve been going through Visual Basic .NET 2003 Resource Kit this morning, looking for goodies I can reuse elsewhere. One of the “metrics” I use is how good console tool support is.

Strictly speaking, this is not a VB issue, it is a .NET issue, and I’m finding myself wandering off to think about the whole issue of console tool support as a concept in Windows systems. The real underlying problem is not one of what classes are available here and there for console tools. The problem is that programmers don’t usually realize that a console application is to an administrator what a class is to a programmer.

A CLI application is really a component, and to be the best at what it does, it needs to be self-contained, use common switches, and understand working with stream for input, output, and error. It needs to be self-describing as well, so that help is just moments away.

I’m not quite sure what the “best” answer is, but there is no doubt that a core library which allows simple, single-step generation of help text and internal primitives for scripts and for compiled applications could make an immense difference to the growth of well-behaved, admin-friendly building block applications.