Here are three approaches to entering Unicode characters in Windows. See the next post for entering Unicode characters in Linux.
Alt – x
In Microsoft Word you can insert Unicode characters by typing the hex value of the character then typing Alt-x. You can also see the Unicode value of a character by placing the cursor immediately after the character and pressing Alt-x. This also works in applications that use the Windows rich edit control such as WordPad and Outlook.
Pros: Nothing to install or configure. You can see the numeric value before you turn it into a symbol. It’s handy to be able to go the opposite direction, looking up Unicode values for characters.
Cons: Does not work with many applications.
Alt – +
Another approach which works with more applications is as follows. First create a registry key under
HKEY_CURRENT_USER of type
EnableHexNumpad, set its value to 1, and reboot. Then you can enter Unicode symbols by holding down the Alt key and typing the plus sign on the numeric keypad followed by the character value. When you release the Alt key, the symbol will appear. This approach worked with most applications I tried, including Firefox and Safari, but did not with Internet Explorer.
Pros: Works with many applications. No software to install.
Cons: Requires a registry edit and a reboot. It’s awkward to hold down the Alt key while typing several other keys. You cannot see the numbers you’re typing. Doesn’t work with every application.
Another option is to install the UnicodeInput utility. This worked with every application I tried, including Internet Explorer. Once installed, the window below pops up whenever you hold down the Alt key and type the plus sign on the numeric keypad. Type the numeric value of the character in the box, click the Send button, and the character will be inserted into the window that had focus when you clicked Alt-plus.
Pros: Works everywhere (as far as I’ve tried). The software is free. Easy to use.
Cons: Requires installing software.
Microsoft did an experiment similar to the Pepsi Challenge from years ago.
Microsoft asked people their opinions of Windows Vista then asked them to take a look at Mojave, a supposedly new version of Windows. See The Mojave Experiment. Not surprisingly, people had favorable things to say about Mojave. There wouldn’t have been a Mojave website otherwise. To Microsoft’s credit, they do give some details of the experiment on the website. When the participants were told that “Mojave” is really Vista, their reactions were very similar to the Coke fans who were told that they’d just chosen Pepsi.
There’s a deeper analogy between the Mojave Experiment and the Pepsi Challenge. One reason Coke fans often preferred Pepsi in a blind taste test is that they didn’t drink much of the samples. Pepsi is sweeter than Coke, and so people may prefer a sip of Pepsi to a sip of Coke, even if they would prefer a can of Coke to a can of Pepsi. People may be impressed with a demo of Vista but frustrated when they have to use it for a few days. On the other hand, I don’t doubt that many people have been prejudiced against Vista and would enjoy using it if they gave it a chance.
On the Windows PowerShell blog, Jeffrey Snover links to a article in Linux Magazine by Narcus Nasarek comparing Windows PowerShell and Linux’s bash shell.
The article’s sequence is unexpected. Not until near the end of the article does Nasarek get to the main difference between PowerShell and bash: PowerShell pipes objects, not text. Nasarek says regarding PowerShell’s object pipeline “Bash cannot compete here.” He says that the disadvantage of bash in this regard is that “it relies on the abilities of external programs to handle data structures.” That is an understatement. The disadvantage of bash is that it requires fragile, ad hoc text manipulation to pluck data out of the pipeline.
Nasarek is being fair to PowerShell, but he was limited by space. He had only two pages for his article, and only about half of those two pages were devoted to text.
Windows has never made it easy to read long environment variables. If I display the path on one machine I get something like this, both from cmd and from PowerShell.
C:bin;C:binPython25;C:binTeXmiktexbin;C:binTeXMiKTeXmiktexbin;C:binPerlbin;C:ProgramFilesCompaqCompaq Management AgentsDmiWin32Bin; ...
The System Properties window is worse since you can only see a tiny slice of your path at a time.
Here’s a PowerShell one-liner to produce readable path listing:
$env:path -replace ";", "`n"
C:Program FilesCompaqCompaq Management AgentsDmiWin32Bin
(If you’re not familiar with PowerShell, note the backquote before the n to indicate the newline character to replace semicolons. This is one of the most unconventional features of PowerShell since backslash is the escape character in most contexts. Because Windows uses either forward or backward slashes as path separators, PowerShell could not use backslash as an escape character. Think of the backquote as a little backslash. Once you get over the initial shock, you get used to the backquote quickly.)
Update: It occurred to me after the original post that there’s an even simpler way to display the path.
Two of my favorite cmdlets from the PowerShell Community Extensions are
out-clipboard. These cmdlets let you read from and write to the Windows clipboard from PowerShell. For example, the following code will grab the contents of the clipboard, replace every block of white-space with a comma, and paste the result back to the clipboard.
(get-clipboard) -replace 's+(?!$)', ',' | out-clipboard
I saved this to a file
comma.ps1 in my path and run it when I get a list of numbers from one program delimited by newlines or tabs and need to make it the input to another program expecting comma-delimited values. For example, turning a column of numbers into an array for R. I copy one format, run
comma.ps1, and paste in the new format.
In case you’re curious about the mysterious characters in the script,
s+(?!$) is a regular expression describing where I want to substitute a comma. The
s refers to white-space characters (tabs, spaces, newlines) and the
+says this is repeated one or more times. So match one or more consecutive white-space characters. That would be enough by itself, but it would replace trailing white-space with a comma too, so I might get an unwanted comma at the end. The sequence
(?!$) fixes that. The
$ matches the end of line. The
(?! before and the
) after form a negative look ahead, meaning “except when the thing inside matches.” So taken all together, the regular expression matches chunks of white-space except at the end of the input.
Update: See Manipulating the clipboard with PowerShell
Imagine you find a paragraph on the web that you want to email to a friend. You copy the paragraph. Then you think you should send a link to full article, so you copy that too. You start composing your email and you type Ctrl-V to paste in the paragraph, but to your disappointment you just paste the link. So you go back and copy the paragraph again.
The problem is that the Windows clipboard only holds the most recent thing you copied. Jeff Atwood posted an article a few days ago called Reinventing the Clipboard where he recommends a utility called ClipX that extends the clipboard. After you install ClipX, typing Ctrl-Shift-V brings up a little menu of recent clippings available for pasting.
I’ve been using ClipX for a few days now. It’s simple and unobtrusive. The only slight challenge at first is remembering that it’s available. One you think to yourself once or twice, “Oh wait, I don’t have to go back and copy that again,” you’re hooked.