FOSSwire

While you might associate working with images with big graphical programs like GIMP or Photoshop, ImageMagick is an entirely different animal. It is a suite of command-line programs for converting and manipulating images.

But why would you use a command line program to work with images, which are by definition, graphical? Well, for a start, you don’t have to load up a slow (and dare I say bloated) graphical app just to achieve a simple conversion task: you can fire off the command and have the result done in no time. Also, you can go to pretty much any Linux computer and know that ImageMagick is available — its ubiquity makes it a useful tool to know how to use.

So let’s jump right in to doing some simple, but useful, conversion tasks with ImageMagick.

Change format of a single image

If you have, say, a PNG file that you want in JPEG format, you can simply run convert with the source filename and the desired destination filename, and it will infer the desired format from the destination’s file extension.

For example:

convert source.png destination.jpg

Resizing images

To resize an image with ImageMagick, you can use the -resize command line switch to resize by either a percentage, or with the exact desired dimensions. Note that resize will preserve the aspect ratio of your image, even if you choose exact dimensions that are in a different ratio.

convert source.jpg -resize 75% destination.jpg

convert source.jpg -resize 800x600 destination.jpg

Apply heavier compression to an image

If you want to squeeze down the file size of an image in a lossy compressed format, such as JPEG, you can instruct convert to change the quality attribute.

convert big_file.jpg -quality 60% small_file.jpg

Batch converting from one format to another

So, say you have a folder full of PNG files that you now need in JPEG format. With many applications, you would have to go through the laborious process of opening each image and using Save as to save the file in the new format.

With ImageMagick and the command line, you can convert all the PNG files in the current working directory to JPEG like this:

mogrify -format jpg *.png

Trim off the edges of an image

If an image has too much space around the edges, you can use trim to automatically crop the image. This feature removes any edges that are exactly the same colour as the pixels at the corner of the image.

convert non_trimmed.jpg -trim trimmed.jpg

And there is more…

We really are only scratching the surface of this powerful suite of applications. There is extensive documentation on all its features and there is certainly more to explore if you find yourself using ImageMagick a lot.

For a long time, the Grand Unified Bootloader, or GRUB, has been the standard way of getting a PC to boot into your Linux, or other Unix operating system. The flexibility offered by GRUB makes it easy to dual boot, triple boot… well, actually, do pretty much what you want in terms of installing operating systems on your own computer.

The newer versions of Ubuntu (from 9.10) and their derivatives are going through a transition. The old ‘legacy’ GRUB is giving way to the new GRUB 2. The name is similar and the spirit is similar, but GRUB 2 makes a lot of changes to the bootloader setup. In this post, aimed at people who are already familiar with GRUB Legacy, I hope to outline some of the important differences so you can get up to speed as newer distributions adopt the new bootloader.

Using the Bootloader

For the most part, how you actually interact with GRUB once it has been set up is mostly the same. You still get the same list of operating systems to boot, from which you choose the one you want. It still should be good about auto-detecting other operating systems co-existing on the same machine, such as Windows, and offering you those choices.

A couple of key differences when actually using the bootloader:

• If you have only one operating system on your machine, the menu is bypassed entirely and the machine boots straight away into your OS.
• With the ‘hidden menu’ feature, you now press Shift rather than Esc to show the menu.

Fundamentally, though, it’s pretty much the same thing. You can still, for example, press e when an entry is highlighted to edit the boot commands at runtime, although the key combination to actually boot once you are in this mode has been changed from b to Ctrl-X.

Configuring and Installing

Some really important changes have been made to the way the GRUB configuration file is set up and read by the program once it is running. These changes have been the most frustrating for me personally.

The menu.lst file (or occasionally grub.conf) has gone away, to be replaced by grub.cfg. The format of the file has also changed quite a lot — it now includes its own Bourne shell-like scripting language.

The biggest and most important change, however, is that the grub.cfg file is not meant to be edited manually. (It is certainly possible, but expect your changes to get overwritten without warning.)

Instead, there are a series of scripts that are placed in /etc/grub.d which are executed by the update-grub command in order to generate the grub.cfg file. The names of these files begin with a number, which sets the order in which the scripts are processed.

For example, on my Linux Mint 9 system, I see these files:

00_header  05_debian_theme  06_mint_theme  10_linux  10_lupin  20_memtest86+  30_os-prober  40_custom  README

If you want to add any custom entries to your boot menu, you can use the file 40_custom and set up entries with a syntax very similar to that of GRUB Legacy. Again, in my example, I have a CentOS 5 install co-existing with Linux Mint, but the GRUB 2 auto-detect process doesn’t create a GRUB menu entry that actually will boot the system successfully, perhaps due to the older version of the kernel on CentOS (it even still uses hda,b,c notation to refer to IDE hard drives, rather than the more common sda,b,c). Therefore, I’ve set up a custom entry to boot CentOS:

menuentry "CentOS" {
      insmod ext2
      set root='(hd1,1)'
      linux /vmlinuz ro root=/dev/hdb1
      initrd /initrd
}

As you might guess, you can reorder these different sections of the boot menu by simply renaming the files and setting the number prefix so that those entries are in the desired order. In my example, I could rename 40_custom to 15_custom.

Also notable in /etc/grub.d is the 30_os-prober file, which is designed to search for other operating systems co-existing on your machine, such as Windows, and automatically adding an entry to boot them. This should, in the long run, make dual-boot environments more reliable in the face of changes, as this search process is re-run every time that update-grub is executed.

There is also a /etc/default/grub file which contains more general GRUB 2 settings, including the default timeout before the default choice will be booted, the screen resolution and even whether GRUB makes a beep when it starts.

Once you’re done editing any of those ‘source’ configuration files, simply run update-grub for it to regenerate the main configuration file.

I think the changes in the configuration files are likely to be the biggest hurdle to overcome in the migration from GRUB Legacy to GRUB 2. I’ve spent plenty of time screaming at the way it works in GRUB 2, but am now grudgingly coming to accept it as I learn to keep my customisations in 40_custom and learned where all of the new configuration files are.

For new installations and relatively simple dual-boot environments, GRUB 2 should work just great without too much fiddling.

Useful Resources

Perhaps I am lazy — I’ve only really looked into GRUB 2 for as much as I need to do, which mostly has involved setting up my PC system with a ridiculous number of operating system boot choices.

There are lots of other useful resources out there which can help you to get your head around the changes and get used to the new way of doing things.

• IBM DeveloperWorks: Migrate to GRUB 2
• Grub2 — Ubuntu Community Documentation
• GRUB 2: A Guide for Users — Kubuntu Forums

GRUB 2 isn’t standard across the board yet, with many Linux distributions taking the cautious approach for now and sticking with GRUB Legacy, which still works very well. But with Ubuntu and its derivatives taking the lead on the issue, it would make a lot of sense for anyone involved with administering Linux systems to get used to the new version now.

Have you had experience with GRUB 2? Are the changes good or bad? Feel free to have your say in the comments.

For some reason, text editors are something that us Unix geeks get very passionate about. Whether it’s an argument over which editor is better, or just professing our love for our favourite keyboard shortcuts, it’s an emotive issue.

You might think that a plain text editor is a pretty simple affair. After all, all it has to do is allow you to type stuff in and then change it. Right?

Well, it turns out that there are lots of different ways you can approach a text editor and lots of different feature sets that different people prefer.

Why a text-based text editor?

If you’ve used a desktop Linux distribution recently, you’re probably familiar with programs such as gedit, Kate or maybe LeafPad. These are, of course, text editors, but they are graphical programs.

Text editors that run in the command line environment are what we are looking at here. But why would you use any command line based text editor in preference to a graphical one?

• It will run everywhere. If you need to SSH into a remote server, for example, where you only have access to the command line, these editors will be your only option. So learning one of the common editors can come in very handy.

• Extensible and customisable. The flexibility and power offered by some of these tools is unparalleled. If you don’t like the way the application works, you can tweak it and hack it and script it until you do. Getting the same degree of configurability is much more difficult with GUI apps.

• The keyboard. While there’s a learning curve to any set of keyboard shortcuts, putting in the time to grok the keyboard interface can make text editing much more efficient, especially for doing more complex tasks which would require many clicks in a GUI.

• Geek is the new chic. Seriously, you can’t deny there’s a certain sense of satisfaction one gets from using something really geeky. If you’re into that sort of thing…

So, let’s take a look at three of the most common editors, in alphabetical order.

GNU Emacs

Emacs describes itself as “the extensible, customisable, self-documenting, real-time display editor”. It is arguably the most powerful and configurable text editor available and has a long history. The software contains its own programming language, a version of Lisp called Emacs Lisp. This means that pretty much every feature is customisable, such that you can even have 'applications’ that run inside of Emacs (there is a text adventure game called Dunnet and many other 'games’ for Emacs). It even has a built-in web browser.

As a consequence of its 1970s heritage, for someone that has never used it before, the way it works might be unfamiliar. For example, it refers to the 'Meta’ key, which refers to what is now the Alt key on modern PCs.

It is probably fair to say, however, that its extensibility and programmability is unparalleled. If you do want complete control, Emacs is an über-editor.

Advantages

• Infinitely configurable.
• More than just a text editor — can become a whole operating environment!

Disadvantages

• Quite a steep learning curve, with many keyboard shortcuts to memorise.
• Some argue it is too 'heavyweight’ with resource usage.

GNU nano

Modelled around pico, an editor that derived from the Pine email client (though wasn’t under a free software licence), GNU nano is probably the most lightweight of the three editors here and also probably the easiest for new users to immediately get familiar with.

It, helpfully, lists the most common keyboard commands you might need to use at the bottom of the screen (^ denoting Ctrl), so even if you have never used it before, it is pretty easy to work out how to create a new file and save it without having to read any documentation.

The name implies that it is mean to be small and light — you won’t find masses of unnecessary functionality, as it is designed to be just a text editor, rather than something like Emacs which is a whole platform in itself. You will also have less configurability and options, although it’s still possible to do quite a bit of interface tweaking.

Advantages

• Easy to get started with — common commands are always listed at the bottom of the screen.
• Lightweight and simple, just a text editor with nothing else you may not need.

Disadvantages

• Does not offer the same degree of flexibility and extensibility as other editors.
• For serious editing tasks, a lack of advanced features.

vi/vim

Like Emacs, vi and the 'vi improved’ version, Vim, have been around for some time. The original editor, vi, was written in 1976 for BSD Unix, while Vim was written later, in 1991, for the Amiga. For a long time, it was essentially the standard Unix editor until Emacs gained popularity. Inclusion of vi is still a requirement for an operating system to be covered under the Single Unix Specification and the POSIX standard.

The 'improved’ version, Vim, has an internal scripting language which means that it can be customised in many ways, as well as sophisticated syntax highlighting support.

One of the biggest differences between vi and other editors is that it uses a modal interface. There is an insert mode and a normal mode. Any keys you press are only actually 'typed in’ when you are in insert mode. Any keys you press in normal mode are commands. This can be potentially destructive if you are not careful about which mode you are in! The modal way of working, though, does mean the user avoids frequently having to use modifier keys like Control, which in theory can improve typing ergonomics for experienced users doing heavy editing.

Advantages

• A version will ship on every Unix operating system — you know it will be available.
• Configurable and scriptable.

Disadvantages

• New users might find the modal nature interface very confusing at first.
• Not capable of doing everything as an 'operating environment’ as Emacs can.

Everyone has their own preference…

As I mentioned in the intro, which editor you pick is an emotive issue for Unix geeks. If you’re someone less familiar with the command line, but you still do need to learn a command line-based editor, nano is probably the way to go initially, just because of its simple operation and the fact that it shows you the keypresses you need to make.

If you’re more experienced, you’ll either already have a preference for vi or Emacs and you’ll probably be sticking to it. If you don’t, though, give them both a try and see what you like best.

Personally, I’ve always used vim for my command line editing needs. I am lazy, however. I probably only use a tiny percentage of vim’s functionality, and there are many things I should spend more time learning to speed up repetitive tasks. The point is, though, I can get what I need to done, and whichever system I find myself on, I know there is something there I can use.

What is your favourite editor and why? Are there any editors other than these that deserve a mention? Have your say in the comments.

Keyboard image at top of post is by Flickr user john_a_ward. Licensed under CC-BY 2.0 GB.