Portable Vim in Powershell

Because I have finally been able to replace my work laptop.

Because I’m allowed to install software on a server, but not on the laptop in front of me.

Because corporate security policies are insane.

Because I need a decent text editor.

Because PortableApps is a lifesaver.

I have talked about getting Vim to work in Powershell in the past, but this time around I need to get the portable version of Vim working in Powershell.

The first step, of course, is to download the PortableApps platform and install gVim. Handily, this brings the Vim binary along with it so you just need to point your Vim alias to this.

This is done by editing your $profile so that the following line is included:

set-alias vim "PathToPortableAppsgVimPortableAppvimvim80vim.exe"

Everything else appears to be working as expected, so I can actually get some work done now.

Managing network drives in Powershell

It used to be, in Windows, that the way to map network drives was with the net use command, but with Powershell this has become a bit easier. I haven’t, however, been able to find a simple overview of the commands and their usage so hopefully this will be of use to someone other than me.

There are three commands (cmdlets in Powershell speak) that you need to know about.

Get-PSDrive

This lists the currently mapped drives and a bit of information about them, most usefully the network path that the drive is mapped to. You can also enter the drive letter as a parameter so that

Get-PSDrive C

Tells you that drive C is mapped to the Windows C: drive. Obvious, really, but more useful if you want to know about other mapped drives.

New-PSDrive

This is the cmdlet that maps drives to to shared folders. If I want, for example, to map my Y drive to folder sharedfiles on server Server the command would look like this:

New-PSDrive –Name “Y” –PSProvider FileSystem –Root “\Serversharedfiles” –Persist

The PSProvider switch tells Powershell what sort of data this drive is accessing. Filesystem, obviously, is the filesystem but you can also map to environment variables and other oddities.

The Root switch is needed so that Powershell understands the path name.

The Persist switch tells Powershell that this mapping is persistent so the mapped drive is available every time you reboot. This switch also causes Powershell to create a mapped network drive in Windows which can be accessed via all the standard Windows tools such as Windows Explorer.

Remove-PSDrive

When you no longer need the mapped drive, you can remove the mapping with this command.

Remove-PSDrive Y

Does exactly what you would expect.

Searching multiple files in PowerShell

Today I needed to check several scripts to see which ones used (the same) global field (don’t ask). I was doing this at work and Powershell proved to be surprisingly adept at doing this. All I needed was:

Get-ChildItem "Scripts_Folder" -recurse | Select-String -pattern "Field_Name" | group path | select name

… where Scripts_Folder is the folder containg the scripts and Field_Name is the field I was searching for.

Powershell returned a simple list of all of the files containing the field. I can see me needing to use this again, which is why I’m making a note of it here.

That Linux feeling… on Windows

I have been trying to get along with Windows Powershell at work for the past couple of months and, while it is a huge improvement on the more traditional Windows console, it is nowhere near as functional as the Bash terminal I spend most of my time in when at home. So I started poking around online and ended up on the Cygwin.

Cygwin is:

  • a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows.

This does sound good, but it also sounds like potentially much more than I need. I am, after all, only looking for a terminal that I can use to edit and shunt text files without being driven to curse my keyboard.

Luckily, I do have a small Windows partition on my own laptop, so I thought it would be worth giving it a spin at home before screwing up my work laptop enough to attract the attention of the helpdesk.

Before I go on, I shall reiterate that much of the Cygwin functionality os of no interest to me. I really am just looking for a functional terminal environment that I can use while at work.

The install was easy enough. This being a Windows application, it’s just a case of downloading the setup.exe file and clicking on it. You do need to hang on to this file once the install is completed, though, as it also provides the package management functionality for Cygwin. As someone who frequently bins everything, this felt a tad odd to me – but it’s not a problem.

The install creates its own file structure under C:cygwin64 which took me a moment to find. That said, it makes sense that the *nix environment isn’t mixed up with the rest of the Windows stuff. It’s easy to find and, once you are aware of this, the Cygwin terminal starts in the expected folder.

And onto Vim. This is installed by default, or appears to be. Even though the initial screen says Vi Improved, it does look like Cygwin is actually installing Vi by default.

So I added an alias (alias vim=vi) to my .bashrc and renamed my .vimrc to .virc and then things went a bit wrong as Vi is unable to support any of the functions in my default .vimrc. So, back to the setup.exe file I went where I found and installed vim-minimal.

This does not seem to have helped as I am still seeing a whole bunch of comman not available errors.

I was also rather unnerved when I tried the ftp command and saw my password being echoed back at me as I typed it.

At this point, one of the twins came in and wanted to play Cat and Mouse and I’d had enough of being in Windows, so tinkering was abandoned. But, based on first impressions, the Cygwin Terminal is going to struggle to meet my needs.

The search continues.

Vim in Powershell

Because, why not.

And because I am stuck in Windows Land while at work.

And because I found myself playing around with Windows Power Shell. It’s not as good as Bash by a long stretch, but it is a significant improvement on the old Windows cmd almost-terminal. And, because I like to be able to move from task to task, without having to constantly switch windows, I thought I would give it a try.

The first thing to do, of course, is install a decent text editor. This is easy, a Windows binary exists for Vim so I downloaded and installed it. Then comes the fun bit.

Getting it to work in Powershell isn’t exactly difficult, but there are a few hoops that need to be jumped through and no clear overview of what and where these hoops happen to be. And that’s why I am posting this.

First, you need to allow scripts to run. This is not enabled by default because, obviously, if you have a scripting environment, the last thing you are going to want to do is execute scripts. Fortunately, this is easily checked and altered by means of the execution policy.

To see the current state of your execution policy, use:

Get-ExecutionPolicy

This will probably tell you it’s restricted, in which case you need to tell it to run scripts by typing (or pasting):

Set-ExecutionPolicy RemoteSigned

(You can also set the execution policy to AllSigned or Unrestricted, but RemoteSigned is sufficient for now.)

Next, you need a Powershell profile (why is it that Windows terms all feel like they should be wrapped in a blink tag?), which can be created by typing (or pasting):

new-item -path $profile -itemtype file -force

And now you need to edit your profile to add a Vim alias. You’ll need to do this in Notepad:

notepad $profile

And then paste the following:

set-alias vim "C:/Program Files (x86)/Vim/Vim74/./vim.exe"

# To edit the Powershell Profile
# (Not that I'll remember this)
Function Edit-Profile
{
    vim $profile
}

# To edit Vim settings
Function Edit-Vimrc
{
    vim $HOME_vimrc
}

(Obviously, you will need to amend the Vim path name to match the reality on your system.)

And you’re done.

I’m not sure how much use I will actually get out of Vim at work as my workflow often involves copying and pasting text from one application to another – and for that Notepad++ is probably still a better fit. However, having an additional tool certainly does no harm and I can certainly see cases where having the power of Vim available will be useful. For now, I will use both and see how each fits into my workflow.

And finally, this post was brought you you with the help of Microsoft, Marlon Abastar and Julian Kay.

Pyrrhic Convenience: The Microsoft Poetry Edition

After three attempts, my employer has finally managed to upgrade switch my laptop from Windows XP to Windows 7. Consequently, I have spent much of the morning achieving a zen-like state of frustration as I attempt to decrapify my desktop.

I mean, how hard should it be to point a text editor at a syntax file? Very hard indeed, it appears, because Windows 7 insists on obscuring the file locations behind libraries and ‘helpfully’ shortened path names, thus turning a simple file copy into a never-ending nightmare.

But I got there, eventually, and managed to turn off most of the notifications and other annoyware that comes as standard with Windows and I even changed my desktop background to a nice relaxing landscape. And, boy, do I need to be looking at a lot of relaxing landscapes right now.

Then I noticed that some of the applications weren’t using the Windows 7 themes deciding, instead, to do something completely different. A bit of flipping back and forth between windows confirmed that the software responsible for this unpleasantly jarring effect was… Microsoft office.

Or, to put it another way, the only company unable to properly write Windows applications is Microsoft.

So, back to the internet I went to see if there was any (no-obvious, wholly unintuitive) way of fixing this. As far as I can tell, there isn’t, but I did find this:

All I can see is “White”, “Light Grey”, and “Dark Grey”…which is equivalent to “Stormtrooper White”, Stormtrooper Light Grey”, and “Stormtrooper Dark Grey”. Did the Adams Family design the Office 2013…

Or better still:

Then, you launch the Excel 2013 app…and all the life is instantly sucked right out of Windows 8. You can feel it in your bones. The Office apps are a barren, Boot Hill-esque, cold wasteland….with grey and white tumbleweeds and gravestones. Then, you go back into Metro…and WHAM…it’s the Skittles rainbow monster voraciously attacking everything in sight. Nom nom nom nom. Big blocks of color coming at you….it’s crazy like…wow man…what a Fear and Loathing in Las Vegas trip crazy! You are flying sky high with the bats and stingrays. Life is groovy. You then launch Outlook 2013 and WHAM…there you are…slammed down to the ground…back in Frankenweenie land ready to raise some dead animals or something.

Yes. That’s exactly what it’s like.

Odilon Redon once said:

What distinguishes the artist from the dilettante? Only the pain the artist feels. The dilettante looks only for pleasure in art.

May I suggest a new slogan for Windows 7, Microsoft Office and – I suspect – the whole stable of Redmondware: It’s not for dilettantes.

On the difference between Windows operating systems and Gnu/Linux distributions: An observation

I do like snappy post headings, but that isn’t the point of this post.

Over the Christmas period my parents came to visit and brought with them (among other things) an elderly scanner that had worked fine when attached to a Windows XP laptop but worked not at all with Windows 7. The scanner is a Visioneer 5800 and the problem is that there is no Windows 7 driver for this scanner.

I’d forgotten just how painful it could be to be dependent on proprietary drivers, but this isn’t the point of this post.

We eventually found a workaround over at Tom’s Hardware and the scanner is now scanning. We still have a problem, however, because the software appears to be losing the scanned image and then locking itself up. I suspect that the problem is a configuration issue and that the scanner software is looking for a hidden folder that doesn’t exist. And this brings me to the point of this post.

With the various Linux distributions I have used, configuration information is very easy to find and modify. The distribution works for me and the only limitations are my own ability and willingness to read the necessary documentation. Windows, on the other hand, works against me by hiding configurations here, there and everywhere and by making it pretty much impossible to poke around or to make any changes other than those explicitly permitted by both Microsoft and each and every device manufacturer.

My laptop runs Antergos and I do feel that I am in control of what this machine can and cannot do. A Windows user, on the other hand, is not in control of their machine and has, instead, been trained to accept that the way to solve issues is to buy more stuff.