Shane's Computer Solution Repository

Vi Tip of the Week: What line number am I on?

This is part of a series of tips on using Vi. To see the complete series, click here.

If you are editing a file in vi, and you want to know what line number you are on, it’s very easy to find it: press Control-G, and the status line at the bottom of the screen will tell you! See, for example, the following screenshot taken just after I pressed Control-G:

As you can see, the status line displays the name of the file I am currently editing (in this case, Hamurabi.java), the line number that my cursor is currently on (line 30), the total number of lines in this file (351), how far down into the file I am as a percentage (8% of the way through the file), and which column that my cursor is currently on (column 9).

Depending on which version of vi you are using, your status line may look slightly different. On both a Mac (where the above screenshot is from) and on a Debian Linux box, I see identical status lines. However, with the version of vi on Fedora Linux, I don’t even need to press Control-G, as the status line always tells me which line and column I’m on:

In this case, the “30,9” indicates that my cursor is currently on line 30, column 9. The “6%” on the right-hand side of the status line tells me that the top line displayed in my window is 6% of the way through the file. If I press Control-G now, I get a little bit of additional information:

As with the Mac and Debian versions of vi, I am told the name of the file, how many lines in the file, and how far I am through the file. It’s the same information, just presented slightly differently.

Vi Tip of the Week: Open a file in read-only mode

This is part of a series of tips on using Vi. To see the complete series, click here.

Sometimes I want to open up a file to look at it, but not change its contents. I could use the commands “more” or “less”, but I prefer to use vi for longer files, mostly because I’m so used to using vi. To do so, I can use the command:

vi -R filename

where “-R” tells vi to open the file in read-only mode. Although, I never open it with the -R option; instead I use the command:

view filename

which also opens the file in read-only mode.

Sometimes, though, I’ll be looking at the file, and realize I actually do want to make a change to it. The hard way would be to close the file, then open it again in the regular editing mode, but instead, I can use the command mode to force a write:

:w!

If I use “ZZ” or “:w” to try to write the file, I get an error message telling me that the “readonly” option is set, but if I use the exclamation mark “:w!”, I can force vi to write the file.

Vi Tip of the Week: Go to a specific line

This is part of a series of tips on using Vi. To see the complete series, click here.

Sometimes when I open up a file in vi, I want to go to a specific line. Perhaps I had a compile error on a certain line, and I want to take a look at that line. It’s nice and easy to do: when in command mode, just type the line number, followed by an uppercase G. So, for example, if I type:

35G

I’ll be taken to line 35.

Actually, in the situation I mentioned, there’s an even better way to do it — when I open the file, I can specify what line to go to with the +linenumber option on the command line. For example, to open a file called dummy.txt and go directly to line 35, I can type:

vi +35 dummy.txt

and the cursor will be placed on line 35.

There are a couple variants that I use frequently: if I want to go to the first line, I enter:

1G

and if I want to go to the very last line of the file, I don’t put a number first, just the uppercase G

takes me to the last line.

Vi Tip of the Week: Transpose characters

This is part of a series of tips on using Vi. To see the complete series, click here.

OK, this is my favourite command in vi, not because it’s especially useful, just because I think it’s neat. If you make a typing mistake and get two characters switched around, it’s easy to fix. For example, if I want to type “Linux”, but I mistakenly type “Liunx”, all I have to do is place my cursor on the “u”, use the “xp” (transpose) command, and it swaps the “u” and the “n” around, making “Linux” as I originally wanted.

I sort of lied; this isn’t a single command — it’s two commands that result in transposing the characters. The first command, x, deletes the character under the cursor and saves it in vi’s “unnamed” buffer. Then, the second command, p, spits out what’s in that buffer, placing it after the cursor. So, the result is that the two characters are transposed (fancy word for switched around). What I think is cool is that these two separate commands, x and p, when combined as xp, perform an operation that is easy to remember: xp = transpose! Cool!!!

Vi Tip of the Week: Read the manual!

When I teach a class that is using Linux, I always encourage the students to use the Vi editor, rather than something simple like gedit, just because Vi is so powerful AND you can use it on a terminal. But, the students are often confused by Vi, and because I’ve used it for so long and it’s just second nature to me, I’m surprised at how many students don’t use the great features of Vi and just use it like gedit. So, I thought it would be a good idea to start a series of tips on using Vi, and this is the first one.

This week’s tip: Read the manual! There’s a great manual written way back in the either the late 70s or early 80s by Bill Joy, the creator of Vi. It’s called An Introduction to Display Editing with Vi, and if you work through that, you’re going to know more than probably 95% of the people who use Vi. Anyone who wants to start using the true power of Vi should read this manual. Actually, even as someone who has used Vi since 1982, everytime I re-read the manual I always find some command that I had forgotten about.

Be warned, though, that some of the things described are more relevant to a 1970s timesharing system than today’s computers: do we really have to worry about editing on slow terminals nowadays??? But, for the most part, this is a great manual.

You should be able to do a google search for the manual, or it’s available in the FreeBSD documentation at http://docs.freebsd.org/44doc/usd/12.vi/paper.html.

This is part of a series of tips on using Vi. To see the complete series, click here.

Installing “PortableGit from msysgit” on Windows 7

I wanted to install Aptana Studio 3 onto my Windows 7 machine at work, and according to Aptana’s Getting Started Guide, I needed to have Git installed. According to the Aptana website, the Aptana Studio installer should install “PortableGit from msysgit” for me if I want, but that didn’t seem to happen. So, I did a little searching for some instructions on installing PortableGit, but when I couldn’t really find anything helpful, I came up with a set of instructions on my own.

PortableGit is an implementation of the Git version control system for Windows machines. It uses the very handy MSYS system to provide a Bourne Shell (bash) command line interpreter system. There’s at least a couple different versions of Git for Windows available from these msysgit guys; I like the PortableGit version because it doesn’t mess with my registry, it doesn’t install anything in my Start menu, and if I want to delete it, I only need to delete the files, not run an uninstall program. It’s very self-contained, and I don’t have to worry about it mucking about with my computer. This isn’t the most user-friendly version, but if you’re an old command-line hack like myself, it’s fine. And, for what I’m going to be using it for (letting Aptana Studio use it!), it’s all right.

I grabbed PortableGit from http://code.google.com/p/msysgit/downloads/list (see image below — click the image to see a readable full-size screenshot!).

I selected the file called PortableGit-1.7.11-preview20120710.7z. This was the latest version at the time I downloaded it; of course, if you’re reading this anytime after the day I post it, there may be a newer version! Clicking on that link takes you to this page (again, click the image to see the full-size screenshot):

I clicked on the little arrow on the left side of the filename, and it downloaded the file for me.

Although this is an executable installer, the file can’t be executed as-is – the file extension needs to be renamed from .7z to .exe. Once I did that, I was able to run it.

Note that, depending on your Windows setup, you may need to run the installer as an administrator. For me, I had to find the file in Windows Explorer (I saved it to my Downloads library), then right-click on the file, and select “Run as administrator”. When I did that, I was greeted with the following dialog box:

That location was exactly where I wanted to install it, so I left it at that. Click OK, and the program is installed. If you get an “access denied” error, it means that you need administrator permission AND you didn’t run it as an administrator, so try again.

Once you’ve got the program installed, if you want to learn more about the “Portable” aspect of PortableGit, navigate to the C:\Program Files (x86)\Git folder. There’s a README.portable file that explains everything.

Once we’ve got PortableGit installed, we’re going to want to be able to run it. The program we’ll be running is called git-bash.bat, and that will give you a Bash shell that you can run Git commands in. To be able to run that program, we’ll need to add Git to my list of executable folders (my “path”) so that I can run it from the command prompt. To do so, do the following. Open the Start menu, then right-click on Computer:

From the pop-up menu that comes up, select Properties.

You’ll get a window that is titled “View basic information about your computer”. On the left-hand side of the window, there’s a menu titled “Control Panel Home”; select “Advanced system settings”.

You’ll get a System Properties window. Select the Advanced tab, and then click the Environment Variables… button:

You will get a list of all the environment variables in the system, similar to this:

Right now, I have no Path user variable, but I do have a Path system variable (if I had been smart, I would have scrolled down to show it in my screenshot!). The Path variable tells Windows which folders contain programs to execute from the command prompt or the “Search programs and files” box on the Start menu.

You now have a choice: if you want to add Git to the path for all users, you’ll want to add Git’s folder in the Path environment variable in the “System variables” section (and you’ll need to be an Administrator to do it); if you only want to add it for yourself, you’ll need to add it to (or create) the Path environment variable in the “User variables” section. I’ll just add it for myself. If you have a Path variable, select the Path variable and then click the Edit… button; if you don’t have one (which I didn’t), just click the New… button.

If you’re adding to an existing variable, you’ll get a window that is similar to this:

To the end of the existing value, type a semi-colon (“;”) followed by the complete path to the folder that you installed git in (in my case, C:\Program Files (x86)\Git). The semi-colon is used to separate all the folders on your path.

If you’re creating a new variable, you’ll get an almost identical window that looks like this:

For the Variable name, type in Path. For the Variable value, type in the complete path to the folder that you installed git in (in my case, C:\Program Files (x86)\Git):

Press OK, and you should be good! You can now finish up by pressing OK on the Environment Variables window, OK on the System Properties window, and then close the “View basic information about your computer” window.

Next, let’s make sure it’s installed. We’ll want to run the git-bash.bat file from the command line. Click on the Start menu, then in the “Search programs and files” box in the bottom left corner, type git-bash and press the Enter key:

Your Start menu will go blank, and there will be a “Searching” message displayed, but soon you’ll see the git-bash command prompt:

If you see that, you’ve successfully installed PortableGit!

If you want to learn HOW to use git, I recommend the Git site: http://git-scm.com/. I’d especially read the Pro Git book on that site.

Formatting percentages in Microsoft Word mail merges

When I mark student assignments, I usually put the students’ marks and comments in a spreadsheet, then I do a mail merge to send out the marks to the students. I like doing it this way because then I’ve got a copy of all the comments and marks that I’ve given the students, and I can do some simple calculations to see how effective my teaching has been in different areas of the course material. I’m also more able to be sure that I’m giving similar comments and marks for similar work.

The only problem I have, though, is that when I do a mail merge, the formatting of my calculated numbers is thrown off, and the worst is the percentages. I know that there’s a way to format them correctly, but I can never remember how to do it, and the notes I’ve kept don’t seem to always work, and I’ve never quite got my head wrapped around the way it works. Until now!!!

I ran across this web page that really helped me to understand what’s going on. While it’s still fresh in my mind, I wanted to write a blog post explaining it so that the next time I need to do this, I’ve got something to reference, and hopefully it will be helpful for other people, too!

Note that I’m using Microsoft Office 2010, although that webpage is for Office 2003, so I’m sure it works with other versions.

Update, Feb. 25, 2014: In the comments below, “Anna” mentioned that she’s verified that this also works in Office 2013.

Let’s start off with a simple spreadsheet. I’ll assume I’ve got an assignment with 3 questions on it, each worth 10 marks. I’ll record the marks for the students in that spreadsheet, then have a column that calculates the total marks, and another that calculates the percentage. The spreadsheet looks like this:

Then, I set up a mail merge document in Word, add in the fields from the spreadsheet, and get a document that looks like this:

So that looks OK, but when I look at it in preview mode, I’ve lost all of the formatting on my percentage field:

The problem is that when I do a mail merge, the number is transferred from Excel to Word, but the formatting is not. The solution is to tell Word how I want to format this percentage field. To do that, I need to mess around with “field codes”. A better explanation is probably given here, but here’s a step-by-step description of how I do this.

First, we need to see the field codes. Press ALT-F9 to display the field codes (pressing ALT-F9 again will undo this). You’ll see:

We need to specify that we want to format this field differently. Place the insertion point after the “MERGEFIELD Pct”, and type in:

\# #0.0

The “\#” tells Word that it should format this field as a number, and the “#0.0” tells it which specific format it should use for the number. I find it a little confusing because the octothorpe character is being used for multiple things: both to say that this field should be formatted as a number, and to say how that number is to be formatted. Anyways, “#0.0” tells Word to use up to two numbers before the decimal point and to include a single zero if the integer part of the number is zero, and to use exactly one number after the decimal point, even if that number is 0. As I understand it, “#” means display the digit if you need it or a space if you don’t (when you’ve got a leading or trailing zero), and “0” means always display the digit. Anyways, our field now looks like:

Let’s look at how this gets formatted. Press ALT-F9, then turn off and turn back on the preview results. Now we see:

Well, that’s close, but it’s not quite right, obviously. The problem is that the number is 0.8, not 80 (a decimal number, not a percentage). To get it to display it as a percentage, we need to tell Word to multiply that value by 100. To do this, first we need to highlight the merge field. Highlight “MERGEFIELD” and the name of the field, as shown:

Once you’ve done that, press CTRL-F9 to embed this mergefield into another field. Now we’ve got:

Notice the extra set of curly braces around the mergefield. It is extremely important that the curly braces be added by pressing CTRL-F9; if you type in the braces manually, it’s not going to work.

Once you’ve got this merge field embedded in another field, we can tell Word to do a calculation with it. Add an equals sign in front of the merge field, and “*100” after it; this tells it to multiply the value of that field by 100, making it a percentage rather than a decimal. It should look like:

Now, press ALT-F9 to turn off the display of the field codes, turn the merge preview results off then back on, and then we should see what we want!

I hope this helps!!!

Restaurant review — Flying Piggy’s Bistro in Ottawa

I’m in Ottawa on vacation with my son. After a fun day exploring the Canadian War Museum (which we are really enjoying — we need 2 days to take it all in), we were looking for some place to eat supper. Matthew told me about the UrbanSpoon app, so we loaded that on my iPad, and started looking for a place to eat.

We decided to try a pasta place called Flying Piggy’s Bistro, as the reviews sounded quite positive (91% positive!). It was kind of out of the way from where we’re staying, but I’m glad we tracked it down! I liked it so much, I signed up for an UrbanSpoon account and wrote the following review.

Our main courses were really good, but the soup we had was AMAZING! It was a coconut curry carrot, lamb, and squash soup, and it was fantastic!!! After that, I was really looking forward to the main course. Although it was really good, it didn’t measure up to the soup. I had the fettuccini ragu alla bolognaise, and Sonny-boy had the “flighty boar.” I have had better pasta, but I have absolutely no complaints about the meal.

Overall, I liked the atmosphere of the place — it was a Wednesday night that we went, and it was pretty quiet. Our waiter had a good sense of humour, but wasn’t overbearing. The meal came quick, and was filling. We were both full (and my “little boy” is 6 feet, 235 pounds), so we didn’t have dessert, but the orange triple sec cheesecake sure sounded good!

I thought the prices were a little high, but I’d recommend this place.

We’ve all got a Point of View Gun

I watched the movie “The Hitchhiker’s Guide to the Galaxy” last night. It’s been a long time since I read the book (mid 80s, I think!), so I’m not too sure how closely the movie follows the book. One thing I don’t remember from the book is the Point of View Gun. You can watch the scene where it shows up on YouTube.

Wikipedia probably has the best description of the Point of View gun:

When used on someone, it will cause them to see things from the point of view of the person firing the gun (the Guide says that it “conveniently, does precisely as its name suggests”). According to the Guide, though the gun was designed by Deep Thought, it was commissioned by the Intergalactic Consortium of Angry Housewives, who were tired of ending every argument with their husbands with the phrase: “You just don’t get it, do you?”

In a moment of serendipity, I was reading a presentation from a guy named Matt Webb, I think it’s about design, and he gives a really cool quote in there:

when people start learning something new, they perceive the world around them differently. If you start learning how to play the guitar, suddenly the guitar stands out in all the music you listen to. […] as more and more people have access to things like iMovie, they begin to understand the manipulative power of editing. Watching reality TV almost becomes like a game as you try to second-guess how the editor is trying to manipulate you.

The quote comes from this site, but that seems kind of rambling to me, so just stick with the quote above!

Anyways, I thought that was kind of cool, AND after seeing the Point of View gun in the movie last night, it got me thinking — learn something new, and you’ll see things from a different point of view. Kind of cool, and I wish I was deep enough that I could make that seem cosmic, but I’ll leave that for someone more philosophical than me.

Anyways, I highly recommend reading through that presentation, and even reading the blog post that took me there, talking about the 100 hour challenge.

Upgrading to Fedora 16

I upgraded my Fedora installation from Release 15 to Release 16 today. It was a very smooth upgrade, although I don’t run much on Fedora — mostly trying things out for teaching in class. I was very impressed, though, with how well the upgrade went.

It wasn’t completely seamless, though, but that was my fault. Let me explain. I’m running Fedora in a virtual machine on my Mac, using VirtualBox. My primary Linux box is a Xiao Hu thin client computer, a MIPS processor based system, and I run Debian on it. But, because I’m teaching a Linux class using Fedora, I wanted to be able to test things out and make sure that things I was used to doing in Debian worked similarly on Fedora. Anyways, because I don’t use Fedora full-time, I created a small 8GB disk to hold the OS. Unfortunately, I needed more than that much space to upgrade, and that caused a slight, but easily manageable, hiccup.

My disk is configured with a 500MB /boot partition, a 6GB / partition, and the rest of the disk is used as swap space. With all the packages installed that we use in class, I’m using just under 4GB on my root partition, leaving a couple gig free.

To upgrade from Fedora Release 15 to 16, I installed and ran the preupgrade package. As part of its installation process, it checks to make sure that there’s enough free space available to do the upgrade. Of course, with all the crap I always seem to accumulate, there wasn’t, and it warned me that I needed to free up about half a gig of space. When I did that, the installation process continued, downloading all the upgraded packages (1130 of them!), then the system rebooted and began to install the new release. Unfortunately, during that installation, it again detected that there wasn’t enough space available, and reported I needed to free up another ~800MB of space! I just didn’t have enough available, so I had to stop the upgrade. Amazingly, I rebooted the VM, and I was back in Fedora 15 with no problems! That was a pleasant surprise, because I was worried that I’d be in a half-installed state, but that wasn’t the case.

It was an easy solution; using VirtualBox’s modifyhd command, I was able to increase the size of my virtual disk, increasing it to 12GB, and I created a new partition with that extra 4GB in it. Now, I needed to free up space on the root partition, and most of the space was being taken up in /var/cache/yum, where the upgrade was storing the updated packages. That was easy — I created a yum directory on my new partition, moved the contents of /var/cache/yum into there, then mounted the new partition on top of /var/cache/yum. That freed up enough space on the root partition to proceed.

At that point, I restarted “preupgrade”, and that quickly detected that I had already downloaded all of the updated packages, AND it saw that I now had enough disk space, so it automatically continued the upgrade. That ran without further input from me, so I wandered off to do something else, and when I came back, I had a nice Fedora 16 system running!

So, although I had a problem, I was very impressed by how well the upgrade process recovered from the problem and finished up the upgrade with little intervention from me. Good job, Fedora!