In which i demonstrate that any old DOS hacker can download PowerShell (aka Monad) and teach it to themself, without any prior training or special knowledge, using any old XP machine.

What you need

1. Windows .Net framework version 2.0
2. Powershell (2.2 MB download... that's nothing!! Do it! Do it now!)
3. [Optional: Powershell 'getting started' documentation (i haven't looked at this... that would be cheating)]

Okay -- so kick off the powershell (via the icon in your start menu, or by running 'powershell.exe' [located in C:\Program Files\Windows PowerShell\v1.0 for me.])

You'll be presented with a console, and a prompt.

(continues...)

Here's the prompt...

Windows(R) PowerShell
Copyright (C) 2006 Microsoft Corporation. All rights reserved.

PS C:\Program Files\Windows PowerShell\v1.0>

First thing I wanted to try was a few old faithful DOS commands to see what happened:

PS C:\Program Files\Windows PowerShell\v1.0> cd\
'cd\' is not recognized as a cmdlet, function, operable program, or script file
.
At line:1 char:3
+ cd\ <<<<

okay.. cd\ didn't work... not to worry, i soon found that it does work if you include the space between command and parameter, like so:

PS C:\Program Files\Windows PowerShell\v1.0> cd \
PS C:\>     [Success!!]

I'd read enough about powershell to know that there isn't really a 'CD' command. What's happening here is that powershell has a lot of alias's defined, so that one command will be channelled into another.

There's two distinct and powerful uses for these aliases:

1. They help ease old dos-hacks like me into the powerShell world, by aliasing old command names on top of new cmdLets.
2. They can provide abbreviations for commands, making you a much quicker scripter.

So, I know that cd works... but I want to find out what the real command is that cd is acting as an alias for...

One way to do this, i figured would be to ask for help with the 'cd' command. Because then of course I'd see the appropriate help for the real command that cd is acting as an alias for.

In dos you can often get help by typping the command followed by " /?".

I tried that first... here was the result:

PS C:\> cd /?
PS C:\d>

Weird result... and one i won't go into here. In any case it wasn't the result I expected. SO i slipped on the old riddling hat, i use for particularly riddlesome situations.

Okay, now every script language other than DOS shuns the use of the slash to indicate parameters. (And if only early DOS had used this same rule, the back slash would never have been needed as a path delimiter...)

SO I tried the same request, this time with a hyphen:

PS C:\d> cd -?

The result was about two screens full of information... telling me how to use the set-location command. Two lessons learnt:

1. Use hyphens to indicate parameters, rather than back slashes!

2. "cd" is an alias for "set-location." Got it.

The help text started like this (i've highlighted one part):

NAME
   Set-Location

SYNOPSIS
   Sets the current working location to a specified location.


DETAILED DESCRIPTION
   The set-location Cmdlet sets the working location to a specified location.
   That location could be a directory, a sub-directory, a registry location, o
   r another location stack.

Groovy! You can use "cd" (i.e "set-location") to navigate around the registry.

Infact here's the first example provided by the help text:

EXAMPLES
   EXAMPLE 1

   C:\PS>set-location HKLM:

Okay -- i recognise those letters, 'HKLM' --> 'HKey_Local_Machine' -- one of the root nodes of the registry! Wicked stuff. I heard about this on a scott hanselman podcast, but wasn't really paying attention at the time.

I guessed that 'set-location' is aliased as 'sl' and hopped into the registry, like so:

PS C:\> sl hklm:
PS HKLM:\>

I was happy to see that the parameter here wasn't case-sensitive. I tried a few variations on sl: SL, sL, Sl and they all worked okay too. Either calling a powerShell cmdLet isn't a case sensitive action, or *all* of those aliases are defined (which seemed unlikely). On a whim, and while think idly of jennifer garner i typed:

PS HKLM:\> alias

And i was happy to see a big long list of all the aliases in the system scroll by...

CommandType     Name                            Definition
-----------     ----                            ----------
Alias           ac                              Add-Content
Alias           asnp                            Add-PSSnapin
Alias           clc                             Clear-Content

Right down to...

Alias           move                            Move-Item
Alias           rd                              Remove-Item
Alias           ren                             Rename-Item
Alias           set                             Set-Variable
Alias           type                            Get-Content

Okay -- i could spend a while talking about those, but instead i'll just bring up a summary of the cmdLets that are aliased by my own 'most-used' DOS commands.

Translating Simple DOS Commands to Powershell cmdLets

[sidebar: while i guess i could somehow use 'format-list' to convert the tab-separated list into a html table... i instead used the world's simplest code generator which got the job done quick n easy, like always.

Okay so before I go anyfurther I should pass along this other rule:

They're called 'cmdLets', not commands

You got that?

Getting More Help

Okay i decided i'd like to read some more built in help. I've heard that PowerShell has excellent built in help. But how to get it?

It turns out that 'help' is an alias for 'Get-Help' (the unix-friendly 'man' command also works as an alias for 'Get-Help')

First observation with running these help commands is that the text often scrolls off the screen.

Running help on help (Help -?) tells me this:

"Get-help" and "-?" display help on one page. i.e. they scroll off the screen!

"Help" displays help on multiple pages. i.e. you get this after every screenful:
                                        "<SPACE> next page; <CR> next line; Q quit"

Another great tip in the help about help is to try this:

get-help *

because:

This lists every help file in the system along with what type of
help it is

So, now I've got hundreds of help topics at my fingertips... too many to read and remember in one go. [At this point i went off and wrote 'ShinyPower']

Best of all i know that this 'Get-Help' command is a general way in to the help system.

At this point i've learnt enough simple things that I'm not too afraid of it anymore. I can starting running around in it and really trying things out.

I'll write more about it when i get a chance.

ShinyPower is a little C# app i wrote to automate browsing PowerShell's help files.

The source code and a new version are now available at CodePlex.

New Version out now! Works with Powershell Release Candidate 2 -- Available from CodePlex

If you still want to download the old version... well...

Requires PowerShell RC1 and the .Net Framework version 2.0

It's very rough, and is just a proof of concept really.

  Download ShinyPower (for RC1) (and then unzip) from here.

Q: Why 'Shiny?' A: Firefly.

Q: Any other C# tools/samples that automate Powershell?

A:This Turtle Logo application [called 'MSH Logo'] is wikid. Also, scott hanselman posted up a snippet recently.

The first step in automating powershell is to add a reference to System.Management.Automation.dll, which (for me) was located in:

C:\Program Files\Windows PowerShell\v1.0\

How to use 'ShinyPower'

1. Select the type of help topic you want to read, from the drop down list, top left..
2. Click on the particular help topic, from the listbox at left.
3. Read the help (or syntax details) in the panes on the right.

Say you've just created an application, and it uses a new type of file. This new type of file will be identified by its very own file extension, associated with the new app.

For example, you might use a ".snapper" file extension, even though the file itself is just "xml".

The ".snapper" filename is not very helpful to a user, as it hides the fact that this is an xml file. The only way for a person to work out that this is an xml file, would be to look inside.

Conversely, a ".xml" file extension would be unhelpful to the operating system, as it hides the fact that this is a snapper file. Again, the only way to work out that this is a snapper file, would be to look inside, and find the schema that this document matches (if any) (knowing me, probably none... sorry).

And this is a common scenario, particularly with variations of xml files.

So i'm suggesting a new micro-format, and this micro-format has nothing to do with the current microformat buzz on the internet. This is to do with multiple file extensions, set theory, cascading inheritance, and all sorts of tricky stuff. Yet it's very simple.

You can pick it up in under a minute.

(continues...)

Instead of just one file extension, why not give a file a whole bunch of file extensions, starting with the least specific and ending with the most specific!

An over the top example would be:

MyTimesheetSettings.txt.sgml.xml.snapper

What does this file name mean?

• Everything before the first dot is the name itself.
• After the first dot we have the most general type of the file: it's a text file.
• Then we have a more specific rule: it's an sgml file.
• Then a more specific fact again: this particular sgml file is xml.
• Then a more specific fact again: this particular xml file is of type 'snapper'.

Now this could be useful if, for example, the only verb defined for .snapper files is 'open', but the 'edit' verb is defined for .xml files.

Or maybe on your system, you don't know how to edit xml files, but you do know how to edit text files. Then, right clicking on the file in windows explorer, you'd not only have the choice to open the file with TimeSnapper, for example, but also to edit it with a text editor.

Today we often layer a specific format inside a general open format. And general open formats are built upon more general, more open, formats. (We could be fancy and call it some kind of aristotelian hierarchical classification system... but it's been too long since i read sophie's world, so i'm not gonna keep pretending i remember that stuff)

Anyway, I came up with this idea for a different reason altogether.

Bloody Polyglotics Again!

What if a file combined two languages, intermingled in the one document. For example, what if a file could be opened both as a valid sql file, say, and as a seXml file. Or as a C# file, and a seXml file.

There's a technical name for a program that can be compiled by two different compilers, and after a lot of googling i tracked it down... polyglot!

A more general case: what about files that contain multiple discrete syntaxes in a single document. A common example: a Valid html file might also be a valid xml file. You want to view it as html, but you want to edit it as xml.

_{(Okay we have the xhtml extension for that... but if we invent new extensions for every combination of two or more existing extensions, we'll be looking at a lot of extensions within the next ten thousand years.)}

Or how about a file that combines javascript, css, and html. Perhaps you'd like to edit the css component in one application, the javascript component in another and the html component in a third. Maybe these multiple file extensions could allow for such behaviour.

(In this last case, the applications would need to be clever enough to know the data they're interested in, and to avoid the data they're not interested in. But it's kind a possible.)

(What i'd like to see is a codegenerator that spits out all types of files (it might create ".cs" files, ".config" files, ".sql" files and everything else). But by adding other names earlier in the list ".wscg.cs", ".wscg.config", ".wscg.sql", it can still reserve the right to edit these file types... even though it knows nothing about them. Provided it knows how comments work in the target format, it can embed it's own iXml or seXml tags amongst these comments.... possibly providing enough information to re-generate the files, and identify user edited portions...)

Well, that's my 'microformat' idea of the day. It's only micro-useful, so don't micro-flame me.

A follow on thought from this was covered in yesterday's iXml post.

[Update: renamed as 'Cascading File Types' based on comment from Jonno. Cheers Jonno!]

There. I've said it. XML isn't a mark-up language. I've said it twice. I must mean it. I'd better explain myself, quick.

This thought has been brewing inside my brain for too long now.

XML has always been called a mark-up language, and it's derived from SGML, which is also referred to as a mark up language.

And maybe if enough people speak an untruth often enough, it becomes a sort of quasi-truth. A pseudo factoid, maybe.

My point is... [continues... long]

My point is that while XML is similar to a mark-up language, it is in fact far more brutal than one. It oversteps the line and is, instead, an exclusive document formatting language. In the process it has lost a lot of the benefits of mark-up.

The idea of mark-up, is elegant, light and beautiful when compared to these heavy 'document formatting' techniques we've taken on instead.

Consider a piece of text, that is not marked up:

Take your god damn hands offa her.

If we want to "mark it up" we can use special codes of some sort to impose a second meaning on it:

Maybe we'd use slash characters:

Take your //god damn// hands offa her.

Or in gaXml we might say:

Take your <em/god damn/> hands offa her.

But to mark this text up using xml, we have to be a lot more brutal:

<?xml version="1.0" >
<quote>
Take your <em>god damn</em> hands offa her.
</quote>

See in xml you can't simply mark up the parts of text that we wish to give a special meaning to. We must give a special meaning to every single part of the document. Even if you don't know anything special about the rest of the document. Weird isn't it?

For that reason, XML can never just adding marks/meaning to portions of text: instead it becomes The One True Meaning Of The Document.

So, rather than the markup being placed inside the text, the text is dragged, kicking and screaming into the markup.

Don't get me wrong: I do love XML. I'm just starting to hallucinate about the world beyond it.

The great benefit of XML is that it's easy to write an xml parser, because xml documents are so very machine-readable.

But by using such an all-encompassing format, we destroy any machine-readability that the document might otherwise have had.

For example, a C# document is perfectly machine readable. (Assuming the machine has a C# compiler). Ditto a python document, a ruby document, or a CSS file.

But when we mark up that document using XML, we have to use an all or nothing approach.

Either we embed the C# file inside an XML document, and it can no longer be compiled by a C# compiler.

Or we embed 'xml-like' comments in the C# document, and (since they're not quite XML) they can't be read by any XML parser on the planet. We need a specific "C# with embedded XMl-like stuff" pre-parser to do the job for us. It doesn't matter how many XML parsers there are, cause there aren't a lot of 'pre-parsers' available.

Life After Xml

I'd like to see a simpler mark-up language, that allows for more flexible documents. (They'd still have strict heirarchy and well-formedness, like XML).

I've tinkered with names for it... XXML, X2ML 2XML, iXML,... for this blog entry i'll stick with the name iXml, though i'm not at all attached to it.

XML would be just a sub set of iXML. In other words we'd need to rewrite the genealogy of XML.

Instead of following this old blood line:

<sgml>
  <html />
  <xml>
    <xsl />
    {etc.}
  </xml>
</sgml>

(i.e. xml is a child of sgml, and xsl is a child of xml, etc...)

We'd change it to be:

<iXml>
  <xml>
    <xsl />
  </xml>
  <css />
  <c />
  <c# />		
  <ruby />		
    {etc.}
</iXml>

(i.e. xml is a child of iXml. Css grammar is also a descendent of iXml... so are many other formal grammars, provided they are strict....)

The idea of iXml is that it doesn't need to ruin a document's existing machine-readability (or human readability for that matter).

Anonymous Structure

Thanks to thinking about Linq, anonymous types and some other stuff, i've thought of something else that XML lacks, because of its verbosity. This could never be pushed into XML, but could fit into iXml nicely.

Consider this nice piece of CSV:

1,2,3,4

How would that look in XML?

<?xml version="1.0"?>

<Numbers>

  <Number>1</Number>

  <Number>2</Number>

  <Number>3</Number>

  <Number>4</Number>

</Numbers>

Now the official excuse for this sort of monstrosity goes back to the XML spec, where they say:

Terseness in XML is of minimal importance.

But the problems with the above XML example, are not just it's verbosity, but that it forces us to invent meta-data. The list in its original form didn't impose any kind of type, or name upon the data.

So here's a different feature of iXml: it allows for anonymous "structure-only" markup!

<>

  <>1</>

  <>2</>

  <>3</>

  <>4</>

</>

So in the above case we can see that the data values 1, 2, 3 and 4 are all siblings. We don't need to invent an element name for them, if all we want to impose on them is a heirarchical set of relationships.

_{(I guess a rule would also be needed to define an empty anonymous element, in the example above [since '</>' is already taken to mean an empty closing element. I figure an empty anon element would be written: '< />'. Can't think what you'd use it for... a place holder of sorts i guess.)}

Polyglotics

A polyglot is a person who speaks more than one language. In programming, a polyglot is a document that is valid in more than one language.

It sounds like a dangerous and bad thing. It sounds like a maintenance nightmare.

in fact, polyglotics is already all around us.

A static html document can be polyglotic: combining html and css in a single document.

A dynamic html file will combine three different syntaxes, each delimited in different ways: html, javascript and css.

A worst case scenario document might combine: html, javascript, css, asp, vba, embedded sql, regular expressions, comma separated values, and embedded xml all in the one document!

It's a pity that XML, because of it's over-reaching design, doesn't allow for polyglotics.

An iXml parser would be able to separate those threads out, treat them separately, and even allow different people to work on each of those sections simulataneously...

Alright, i've blurted out too much about my inner-inklings now. Finally here's a rewrite of the designs goals of XML, appropriated for iXml.

1. iXML shall be straightforwardly usable over the Internet. Like duh.
2. iXML shall support WAY MORE applications than XML.
3. XML shall be compatible with SGML. (screw sgml!)
4. It shall be fairly easy to write programs which process documents containing iXML markup.
   _{[Not as easy as XML... but who needs 1,000,000 parsers? A dozen good ones would suffice.]}


5. The number of optional features in iXML will be much higher than in XML... deal with it.
6. documents containing iXML markup should be WAY MORE human-legible and reasonably clear than those dodgy XML docs!
7. The iXml design should be prepared quickly.
8. The design of iXml shall be sorta formal and sorta concise.
9. iXml marking shall be easier to create than XML with it's dodgy "let's take over the entire document" philosophy.
10. Terseness in iXml markup is of relative importance.

Tim Bray, I await your reply. ;-)

Have you ever dragged a folder from one place to another, when you didn't mean to?

Have you ever accidentally dropped a file into the wrong folder?

If so, join the Society For People Who Have Stuffed Up While Dragging And Dropping.

At the SFPWHSUWDAD, we will give you all the support you need.

To join us, just write your name on the back of an envelope, and drop it in a post box near you.

_{(Do try to be very careful not to drop it in a rubbish bin adjacent to a post box though. This has been happening to a lot of our members recently, and we are not sure why).}

_{(Also, if you drop in to see us, be careful not to knock on the door next to ours. That's the offices of "The Society For People Who Get Angry At Anyone Who Knocks On Their Door", and sometimes they can be downright grouchy.)}

(yes i speak from recent, clumsy and painful experience. ;-) )

Well it turns out you can actually use 'goto' statements in C# !!

Conversation overheard in the next cubicle:

DotCom:

Whoever builds the first Online Pet Food Store targeted not at people, but Dogs, will OWN the market Forever!

Let's assign this thought a picture:

Web 2.0:

Whoever builds the first Ajaxian Social Application targeted not at people, but Dogs, will be thought-leader in that knowledge domain Forever!

The picture for Web 2.0 would be:

The article "Functional Programming For The Rest of Us" is a great article, but it scares people off because it is long and has a very very slow start.

But it can be read quickly, if you follow these instructions.

First: Learn this little definition:

"Lambda Calculus" is a type of mathematics for "functions that take other functions as parameters and return functions as results. The function is identified by a Greek letter lambda, hence the system's name."

Got it? Functions in, functions out. Rather than your typical values in, values out.

Now -- when you go to read Functional Programming For The Rest of Us, don't start at the beginning. Here's a link that takes you to the right place to start, a few pages in:

This way you'll be starting at the subheading that looks like this:

The style settles down from there, and you won't need to read about Plato taking a walk in the park. Unless you want to, of course ;-)

Here are four tricks I use to try and encourage myself to write the correct code at the right time.

1. Use the Compiler to catch work that isn't done yet.
   • Before writing a method, write the code that calls that method.
   • That way, when I try to compile, errors will be reported for any methods that aren't yet written.
2. Write a 'TODO:' comment.
   • That way I can still compile but can track down the items that aren't done yet.
3. Write a Unit Test that catches each problem as it is foreseen.
   • That way while my code might compile, nUnit will tell me that the full story is a little more complex.
4. Use Debug.Assert statements to hard-code your assumptions. Helps you find when your assumptions are wrong.

You can bounce from any one of these methods to any other. The order can go something like this:

1. First write 'pseudo code' with each line labelled as 'TODO:'
2. Convert the pseudo code into calls to fictional methods/properties. (Methods/properties that aren't written yet).
3. Next, write the outline of these methods, but populate them with TODO's.
4. Maybe now (or sooner) write unit tests to test the empty methods.
5. As the tests are run, add some todo's or even some code to the methods.
6. ...Continue compiling, writing, testing, planning -- all together.

The advantage of this kind of approach can be that it helps you capture your thoughts (getting-things-done style) before you get too bogged down in the implementation detail. And it does it in a way that leans on the tools available, to ease the burden on your memory.

Sooner or later you do of course have to write the actual code -- but using these tricks to scope out, design and view from a high level, can help you cut down and re-use code, long before you've spent time writing it.

My brother-in-law has recently opened a Thai restaurant in Brisbane, (in Paddington, a very funky suburb)

I've eaten there three times now, and love it more and more each time. If you're in Brisbane, please go along and take all your friends. Mention the website special offer and get a free serve of spring rolls. (Details here).

Of course I'm biased to like the place. But don't forget that I'm a naturally cynical and critical person. So i think my recommendation still has some validity. ;-). Anyway, go there, eat that, enjoy the place, check out the way they specially sculpt the carrots and the potatoes. it's worth the visit for that alone!

The house special is number 26, "Seafood Madness". Damn I'm salivating just thinking about it.

Mmmmmmmmmmmm.