Bringing bash and PowerShell a little closer together

I recently ran across PSReadLine, a project that makes the PowerShell console act more like a bash shell. I’ve just started using it, but it seems promising. I’m switching between Linux and Windows frequently these days and it’s nice to have a little more in common between the two.

I’d rather write a PowerShell script than a bash script, but I’d rather use the bash console interactively. The PowerShell console is essentially the old cmd.exe console. (I haven’t kept up with PowerShell in a while, so maybe there have been some improvements, but it’s my impression that the scripting language has moved forward and the console has not.) PSReadLine adds some bash-like console conveniences such as Emacs-like editing at the command prompt.

Update: Thanks to Will for pointing out Clink in the comments. Clink sounds like it may be even better than PSReadLine.

PowerShell logo

PowerShell for Developers

PowerShell was written first and foremost for Windows system administrators, and the benefits to this community are clear. It’s not as clear what developers should make of PowerShell.

Administrators can learn PowerShell as a shell first, and gradually transition from interactive use to scripting. They may learn PowerShell as their first programming language and not even give too much thought to the language per se. But a developer has to ask why and when to use PowerShell rather than another language, such as C#.

Doug Finke’s new book Windows PowerShell for Developers is “for developers” in a couple ways. First, the style of the book is geared toward developers. The book is small, less than 200 pages, because the author assumes the readers are experienced Windows developers who want to focus on what PowerShell adds to what they already know. Second, the book focuses on tasks a developer might want to do. Rather than show you how to create a new Active Directory user, as many PowerShell books would, this book covers topics such as

  • code generation
  • static analysis
  • interfacing with C#
  • embedding PowerShell in your application
  • working with XML and JSON
  • interfacing with Excel
  • creating DSLs.

So why should software developers use PowerShell? And what tasks should they do in PowerShell? One answer to the first question, implicit in the book’s examples, is that PowerShell makes it possible to carry out common tasks with little code. Another answer explicitly given in the book is integration.

Given PowerShell’s growing integration with the rest of the Windows platform, as PowerShell grows, so does your application.”

The book is full of examples of what tasks a developer might want to do in PowerShell. The examples I found most interesting were embedding PowerShell to provide a scripting language for your application and creating DSLs in PowerShell.

One pattern in the examples is text munging, whether that text is source code or common data file formats. Another pattern is integration, especially integrating Microsoft technologies. PowerShell is designed to make it possible to solve these kinds of problems with a minimum of ceremony.

I’ll close with a couple reasons why might a developer not want to use PowerShell in my opinion. The first is frequency of use. Although PowerShell can solve many problems with significantly less code than C# would require, you have to learn PowerShell first, and you have to use it frequently enough to remember it. You have to use PowerShell enough to repay the time invested in learning and practicing it.

The second reason is size. The C# language and the Visual Studio IDE were designed for large projects, but scale down fairly well for smaller projects. PowerShell was designed for the command line, but scales fairly well for large scripts. If you use PowerShell and C#, you’ll have to decide at what size you want to switch from one language to the other.

Related posts:

Giveaway: PowerShell in Depth

About a month ago I gave away a copy of Learn Windows PowerShell 3 in a Month of Lunches that Manning provided. Now I’m giving away a copy of PowerShell in Depth: An administrator’s guide by Don Jones, Richard Siddaway, and Jeffery Hicks.

To enter the drawing, please leave a comment below. I’ll draw a winner from the comments received by the end of the day Monday, July 30 in my time zone.

This book is part of Manning’s early release program. The winner will receive the current version of the book in electronic form and updates as they come out.

Related links:

Learn PowerShell as a shell first

When I was learning PowerShell, I thought of it as a scripting language that has a shell. But the right way to think of it may be the opposite, a shell that has a scripting language. Apparently others have followed this same change of perspective.

Don Jones and Jeffrey Hicks open their new book Learn Windows PowerShell 3 in a Month of Lunches by explaining that they first saw PowerShell as a VBScript replacement and taught it that way.

Since late 2009, however, a shift has occurred. More and more administrators who don’t have prior VBScript experience have started trying to learn the shell. All of a sudden, our old teaching patterns didn’t work very well, because we focused on scripting and programming. That’s when we realized that PowerShell isn’t really a scripting language. It’s really a command-line shell where you run command-line utilities. Like all good shells, it has scripting capabilities, but you don’t have to use them, and you certainly don’t have to start with them.

[Don Jones wrote the first edition of the book, which I haven’t read. This quote comes from the second edition, coauthored with Jeffrey Hicks.]

Other PowerShell books I’ve read felt more like a programming language book than a book on a shell, more like, for example, The C Programming Language than The Linux Command Line. The latter seems to be a better analog for the new PowerShell 3 book: emphasis on interactive use first, programming second. At least that’s my first impression. The book isn’t finished yet — it’s part of Manning’s Early Release program — and I haven’t yet read all of the part that has been released.

If you’d like a chance to win a copy of Learn Windows PowerShell 3 in a Month of Lunches, please leave a comment below. I’ll draw a winner and the publisher will send you a copy of the book.

Update: I’ll draw a winner on Friday, June 29. Comments need to be posted by midnight Thursday in my time zone.

Related links:

Scripting and the last mile problem

From Bruce Payette’s book Windows PowerShell in Action:

Why do we care about command-line management and automation? Because it helps to solve the Information Technology professional’s version of the last mile problem. The last mile problem is a classical problem that comes from the telecommunications industry. It goes like this: the telecom industry can effectively amortize its infrastructure costs across all its customers until it gets to the last mile where the service is finally run to an individual location. … In the Information Technology (IT) industry, the last mile problem is figuring out how to manage each IT installation effectively and economically.

To manage this infrastructure you need a toolkit. Why not use the same toolkit for operations that was used for development?

This toolkit cannot merely be the same tools used to develop the overall infrastructure as the level of detail required is too great. Instead, you need a set of tools with a higher level of abstraction.

Related post:

Kibi, mebi, gibi

Computers like powers of 2, people like powers of 10, and the fact that 210 is approximately 103 makes it easy to convert between the two powers.

A kilobyte is 1000 bytes like a kilogram is 1000 grams. But the former is only approximate and the latter is exact. A kilobyte is actually 210 = 1024 bytes. Similarly a megabyte is 220 or approximately 106 bytes and a gigabyte is 230 or approximately 109 bytes. About 10 years ago the International Electrotechnical Commission (IEC) introduced new units to eliminate this ambiguity. The prefix “kibi” means exactly 210, “mebi” means 220, and “gibi” means 230. (The IEC also introduced tebi, pebi, exbi, zebi, and yobi as binary analogs for tera, peta, exa, zetta, and yota.)

I’ll give arguments for and against using the new units and conclude with a note about their implementation in PowerShell.

Pro

The number of bytes in a kilobyte is about 2.5% larger than the number of grams in a kilogram. But the number of bytes in a megabyte is about 5% larger than the number if grams in a megagram. Every time you go up by a factor of 210, the approximation degrades about another 2.5%. So a terabyte is almost 1.1 trillion bytes. (Why does the quality of the approximation (2^10)k ≈ 103k by about 2.5% for each increment in k? Because by the binomial theorem, (1 + 0.024)k ≈ 1 + 0.024 k.) At larger sizes, the traditional prefixes become progressively more misleading and hence the need for more precise alternatives is greater.

Another advantage to the new prefixes is that “kibi, mebi, gibi” is reminiscent of “veni, vidi, vici.”

Con

The only thing special about decimal powers of 2 — 210, 220, 230 etc. — is that they are approximately round numbers in base 10 that have traditional prefixes associated with them. From a computer hardware perspective, numbers like 216, 232, and 264 are more natural. If you’re not going to use the traditional prefixes, abandon them rather than create near copies. Just state the number of bytes, using scientific notation if necessary.

PowerShell

In Windows PowerShell, the units kb, mb, and gb to mean 210, 220, and 230. For example, if you type 2mb + 5gb at the PowerShell command prompt, the result is 2102272. If you really want to compute 2×106 + 5×103 and can’t do it in your head, you could type 2e6 + 5e3.

Bruce Payette commented on this feature of PowerShell in his book PowerShell in Action.

Yes, the PowerShell team is aware that these notations are not consistent with the IEC recommendations (kibabyte, and so on). Since the point of this notation is convenience and most people in the IT space are more comfortable with Kb than with Ki, we choose to err on the side of comfort over conformance in this one case. Sorry. This particular issue generated easily the second most heated debate on the PowerShell internal and external beta tester lists.

Updating “PowerShell Day 1″ for PowerShell version 2.0

Last year I wrote a little 10-page booklet called PowerShell Day 1. It covers many of the things I wish I had known when I started using PowerShell.

  • How do I configure PowerShell?
  • How do I make PowerShell launch faster?
  • How do I get documentation?
  • Why did PowerShell make some of the design decisions they did?
  • Once I’ve written some useful functions and scripts, where do I put them?
  • Where can I find more PowerShell resources?

Now I’ve started updating the booklet to reflect changes in PowerShell version 2.0. I haven’t had a lot of experience with version 2.0 and would appreciate your help updating the booklet. I have put a link to an alpha version of the update for version 2.0 on the download page.

PowerShell 2.0 for Windows XP etc.

PowerShell version 2.0 shipped with Windows 7 and with Windows Server 2008 R2, but it only recently became available for other versions of Windows.

The release of PowerShell 2.0 has been more like a leak than a product launch. The announcement page hardly reads like an announcement. The title reads “Description of the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.” What’s this “Windows Management Framework”? I’ve never heard of that. I just want the new PowerShell. The first time I saw this page was when someone sent me a link saying PowerShell 2.0 was available for XP. I thought they’d sent me the wrong link by mistake because I didn’t see anything about PowerShell at first. Only if you scroll down to the middle of a long page can you see links to download PowerShell.

I expected something more like the following.

PowerShell 2.0 Released

Download for your platform:

Related links:

Reviewing catch blocks

Here’s an interesting exercise. If you’re writing code in a language like C# or C++ that has catch statements, write a script to report all catch blocks. You might be surprised at what you find. Some questions to ask:

  • Do catch blocks swallow exceptions and thus mask problems?
  • Is information lost by catching an exception and throwing a new one?
  • Are exceptions logged appropriately?
  • Are notification messages grammatically correct and helpful?

Here’s a PowerShell script that will report all catch statements plus the five lines following the catch statement.

Related post: Finding embarrassing and unhelpful error messages

Finding embarrassing and unhelpful error messages

Every time your software displays an error message, you risk losing credibility with your users. If the message is grammatically incorrect, your credibility definitely goes down a notch. And if the message is unhelpful, your credibility goes down at least one more notch. The same can be said for any message, but error messages are particularly important for three reasons.

  1. Users are in a bad mood when they see error messages; this is not the time to make things worse.
  2. Programmers are sloppy with error messages because they’re almost certain the messages will never be displayed.
  3. Error conditions are unusual by their very nature, and so it’s practically impossible to discover them all by black-box testing.

The best way to find error messages is to search the source code for text potentially displayed to users. I’ve advocated this practice for years and usually I encounter indifference or resistance. And yet nearly every time I extract the user-visible text from a software project I find dozens of spelling errors, grammar errors, and incomprehensible messages.

Last year I wrote an article for CodeProject on this topic and provided a script to strip text strings from source code. See PowerShell Script for Reviewing Text Shown to Users. The script looks for all quoted text and text inside XML entities. Then it tries to filter out text strings that are not displayed to users. For example, a string with no spaces is more likely to be a file name or some other code fragment than a user message. The script produces a report that a copy editor can then review. In addition to checking spelling and grammar, an editor can judge whether a message would be comprehensible and useful.

I admit that the parsing in the script is crude. It could miss some strings, and it could filter out some strings that it should keep. But the script is very simple, less than 100 lines. And it works on multiple source code types: C++, C#, XML, VB, etc. Writing a sophisticated parser for each of those languages would be a tremendous amount of work, but a quick-and-dirty script may be 98% as effective. Since most projects review 0% of their source code text, reviewing 98% is an improvement.

In addition to improving the text that a user sees, a text review gives some insight into a program’s structure. For example, if messages are repeated in multiple files, most likely the code has a lot of “clipboard inheritance,” code copied and pasted rather than isolated into reusable functions. A text review could also determine whether a program is concatenating strings to build SQL statements rather than calling stored procedures, possibly indicating a security vulnerability.

PowerShell news

I found out some PowerShell news by listening to the PowerScripting podcast this morning. Here are a couple things I found interesting. See the podcast show notes for more news.

First, a new version of the PowerShell Community Extensions came out last week, version 1.2. See Keith Hill’s summary of the changes.

Second, Bruce Payette is working on a second edition of his book PowerShell in Action. You can get an “early access” version of the book through the publisher, Manning.

Adding fonts to the PowerShell and cmd.exe consoles

The default font options for the PowerShell console are limited: raster fonts and Lucida Console. Raster fonts are the default, though Lucida Console is an improvement. In my opinion, Consolas is even better, but it’s not on the list of options.

Mastering PowerShell by Tobias Weltner explains how to expand the list of font options for the PowerShell console. The same trick increases the list of font options in the Windows command prompt cmd.exe as well. The book is free for download. See page 16 for details. However, I have two comments about the instructions it gives.

First, the book says “The name must be exactly the same as the official font name, just the way it’s stated under [registry key].” However, the Consolas font is listed in the registry as “Consolas (True Type)”. You should enter “Consolas” and leave out the parenthetical description.

Second, the book says “the new font will work only after you either log off at least once or restart your computer.” When I tried it, logging off was not sufficient; I had to reboot my computer before the font change would work.

Update: In order to make this post self-contained, I’ve added below the necessary information from Mastering PowerShell.

Run regedit.exe and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionConsoleTrueTypeFont.

Right-click in the panel on the right side and create a new string value. Name that value “0” or “00” or however many zeros you need to create a new key. That string’s value is the name of the font to add.

Update: See Necessary criteria for fonts to be available in a command window

Related posts:

Improved PowerShell prompt
A couple thoughts on typography
Better R console fonts

Comparing the Unix and PowerShell pipelines

This is a blog post I’ve intended to write for some time now. I intended to come up with a great example, but I’ve decided to go ahead and publish it and let you come up with your own examples. Please share your examples in the comments.

One of the great strengths of Unix is the shell pipeline. Unix has thousands of little utilities that can be strung together via a pipeline. The output of one program can be the input to another. But in practice, things don’t go quite so smoothly. Suppose the conceptual pattern is

A | B | C

meaning the output of A goes to B, and the output of B goes to C. This is actually implemented as

A | <grubby text munging> | B | <grubby text munging> | C

because B doesn’t really take the output of A. There’s some manipulation going on to prepare the output of A as the input of B. Strip these characters from these columns, replace this pattern with this other pattern, etc. The key point is the Unix commands spit out text. Maybe at a high level you care about programs A, B, and C, but in between are calls to utilities like grep, sed, or awk to bridge the gaps between output formats and input formats.

The PowerShell pipeline is different because PowerShell commands spit out objects. For example, if the output of a PowerShell command is a date, then the command returns a .NET object representing a date, not a text string. The command may display a string on the command line, but that string is just a human-readable representation. But the string representation of an object is not the object. If the output is piped to another command, the latter command receives a .NET date object, not a string. This is the big idea behind PowerShell. Commands pass around objects, not strings. The grubby, error-prone text munging between commands goes away.

Not all problems go away just because commands pass around objects. For example, maybe one command outputs a COM object and another takes in a .NET object. This is where more PowerShell magic comes in. PowerShell does a lot of work behind the scenes to implicitly convert output types to input types when possible. This sort of magic makes me nervous when I’m programming. I like to know exactly what’s going on, especially when debugging. But when using a shell, magic can be awfully convenient.

PowerShell browser toolbar

Shay Levy created an amazing browser toolbar for PowerShell. The toolbar works with IE and Firefox. It updates itself using data that Shay maintains. It lets you do Google searches tailored to PowerShell sites, lists popular PowerShell blogs, and has a menu for a wide variety of PowerShell resources. Shay released his toolbar back in June 2008, so this is old news to people more in the know than I am, but I just found out about it yesterday.

I’m not a big fan of toolbars. I installed the toolbar but will keep it hidden most of the time. But I’m glad I installed it just to see Shay’s list of resources.

Shay created his toolbar using Conduit, something else I’d not heard of. Looks like Conduit makes it easy to create other similar toolbars. (Easy in the sense of programming effort; I’m sure a lot of work goes into keeping the resource lists up to date once you’ve created the toolbar.)