Book review: Inheritance cycle

I just finished up the last book 'Brisingr' of the Inheritance cycle, amidst all the more important things I have neglected. This is not a new novel now, and also popular, so I realise I might not be adding much to the very many discussions of the book all over the net. Even so, just to flex my fingers more than anything else, I will attempt to review it.

It is surely not great literature, but then great literature is generally greatly boring. It is a fantasy epic, and expectedly quite heavily borrowed from the paragon works in the field, Star Wars, Lord of the Rings, and probably many others which I do not know, and I guess neither would most of the people reading this blog. This brings us to an interesting point, I believe it would be a great adventure ride for anyone unfamiliar with the genre. Me personally, I say I still enjoyed it. The love of Christopher Paolini for those works is obvious, as he literally takes delight in following the various chapters of the story, of narrating the events happening around the characters. These do devolve to highly stereotyped stuff sometimes, like the depiction of the various races, the elve's niceties, the egg-headedness of dwarves etc etc. The sentence constructions are simplistic and conversations in general very sophomoric, and some moments repeated over and over(Roran kissing Katrina, Saphira comments arrogantly asserting ehr strength). Most characters even speak the same way. Paolini's inexperience is also noticeable, as the plots tend to be non-intertwined and story progresses separately from character to character(Arya hardly plays a role in Book 3).

But the plot does keep you guessing. Paolini does not build up suspense, but the way story evolves is not obvious. I loved the fact that we have an actual main character and are being told the story from the hero's point of view. We don't have a gang of heroes(or a fellowship), and neither are we barred from the main character's or even the dragon's thinking process( certain white wizards comes to mind). Although character development is not a particularly strong feature of the novels, like I still haven't quite figured out Arya/Orrin/Murtagh, but it does very well with Eragon/Saphira growth from adolescence, and Roran's development in Brisingr is specially worth noting. The paraphernalia of characters is small, but not unsatisfactory. Magic is developed well, as are the mind-extension and mind-control abilities. The world is described in suitable detail without being overwhelming. Depictions of supporting characters, like the herbalist Angela, werecats, the raven, are simplistic, but find a way to fit together.

The third book feel a little stretched out, and you tend to more than once, just glaze over the chapters. The ascension periods, first of Nasuada, then Orik, descriptions of the elvish/dwarvish world tend to be onerous, but I can't think of any fantasy novel not suffering from such episodes. It feels odd sometimes that a single tyrant has the whole population of Alagesia by their balls. Not the mention that all his minions, the Forsworn have already been killed by a single man, Brom, and that without his dragon.

To summarise, I believe the Inheritance cycle is a nice and not-so-light introduction to anyone new but interested in reading fantasy epics. Adept readers however, aren't missing much should they skip it. Without a doubt though, a great work for any guy who is just out of his teens.

I shall provide a closure with a list of incidents from LOTR and Star Wars, which might strike a familiar tone with readers of Eragon. I am in no position to judge the intended/coincidental nature of the parallels however.

Star Wars -
Jedi, the peacekeepers, killed.
Luke Skywalker living with his relatives.
ObiWan lurking nearby.
Message from Princess Leia.
Luke Skywalker's foster family killed.
Luke and ObiWan make a run for it.
ObiWan gives Luke a Jedi sword.
(End of Empire strikes back) Darth Vader: I am your father!!
A master Jedi(Yoda) in hiding.
Yoda keeps Luke's secret inheritance from him.
(Return of the Jedi) Eragon returns to Yoda

LOTR
Love story: Man and Elf
Name/Character similarities
Aragorn:Eragon
Arwen:Arya
Gandalf:Gladr
Naz'gul: Raz'zoc

This might be stretching it a bit:
Fellowship: Eragon's company of Elves
Saruman: Murtagh (Both were good, but joined the evil)

For more paranoia, check out tvtropes.

The Command History feature

Adapted from: http://www.talug.org/events/20030709/cmdline_history.html

Well there are a ton of linux commands. The general trend is, you want to tweak something, you search, you google, and somehow accomplish it, and then a couple of months later, get in a situation you have to do it all over again, and with no memory how you did it.
Enter the bash history feature....

Type at the terminal.

> history

The list of commands you see are the recent commands you have typed, along with an index number. You can certainly look for the command yourself and then type it character by character by hand, but there are better ways.

First, you must be familiar with the reverse search concept, which is actually pretty intuitive. All search features search your command memory in the reverse order in time, ie the first command you are given is the one you typed latest. The older commands are accessed later. Get it?

There are three ways the history is generally accessed.

The ! operator

>!text

This runs the command whose fist part matches whatever text you have given it. however, remember the text part cannot contain blank spaces..
ex

>gedit abcd
>!g
gedit abcd

You can also give arguments to the commands, like

> !g xxx
gedit abcd xxx

Grep
Remember the index numbers we got along with the commands with the history command? We can also call them with the ! operator.
Just type !num at the terminal, and it will run the relevant indexed command.

>!534
gedit abcd

But its quite a pain to scroll down the history list searching for the required command. The standard command format in such cases is

> history | grep 'what-ever-you-remember-about-the-command'

Remember 'what-ever-remember-about-the-command' should be a contiguous piece of string in the command.
Ex, I am searching for what options I gave mplayer last time, so that it looped the playlist 5 times

>history | grep 'mplayer' | grep 'loop'

I recommend us to stop for a couple of minutes here and take a few deep breaths so fully sink this in, and think of all the situations where we would have loved to do this. B-)

ctrl-r feature
Here whatever you type is searched backwards in time. You can erase what you have written, but remember the direction of search is always the same! That means that once you have reached a command, you can change your query, but the search will be limited to the time earlier that command execution.

Time for an example.
Suppose you don't remember where was the C++ source file you were editing last time. However, chances are, you had compiled it with g++ before leaving. So press r while pressing ctrl, and get the reverse-i search prompt. Now type 'g++'(without the quotes)

(reverse-i-search)`g++': g++ h_def2.o h_def.o -o h_def

erase and type cd

(reverse-i-search)`cd': cd /home/name/Projects/cmm

You get the command you had given the terminal to change to the code directory! The technique might not be useful always, but you get the idea.

Thats it for this time I guess, I hope you learned something useful.

Simple Linux Process Management

Well, if you are from the windows background, you are probably in love with the Ctrl-Alt-Del combination, symbolizing the ultimate solution to all your worries. Surely you didn't believe linux would make you relinquish your sanity tool? Gnome provides you a very similar interface, with its System Monitor. However, I will be describing operations are the command line, for an introduction to GUI, check for other great links on net.

Basic theory
Processes in linux(and elsewhere too) are basically programs currently running on your system. For example, you might have a  VLC player process, a Pidgin process, 2 of firefox etc.

Here you should ask 'How are processes created'? Basically one process can spawn other new processes. Like, the terminal is one process, and entering 'emacs &'  starts a new Emacs process. One important concept is of parent-child processes. In simplest terms, when a process A spawns processes B and C, the processes B and C are said to be the child of A and process A is the parent of B and C. This is important as parents and children can have some special mechanisms for inter-process communication(processes cannot exchange data among themselves in general). There is no concept of siblings though, and B has no special association with C, apart from them being the children, i.e. process group of A.

You might ask, how was the first process created? Well, the first process is always the 'init' process, which is formed into existance at linux bootup. All subsequent processes are basically the dynasty of init.

Commands
So much for theory, you surely want to see some demo of this stuff now. Give the command

pstree

at the command prompt. What you get, is the tree structure of the processes in your system. You can see 'init' is at the top, and it has (among others) cron and gnome-terminal in its children. Your own terminal is a subchild shell([bash] in my case) under gnome-terminal. Multiple processes corresponding to the same program are displayed at a number in the tree instead of multiple nodes(like 2*[bash], if I have two terminals open).

Now for some action. Basically, to control processes(anything, for that matter), you need to specify which process,and what action. Process are specified by their PID, which is a unique number for each process, and actions are specified by signals. Signals are general identifiers, and each process has the its own action defined with respect to each of these identifiers. Processes need not specify all the signals though, in which case, nothing will happen if you pass those process those signals.

Give the command

ps -aux

This basically gives all the processes active on your system, sorted according to pid(read the man pages for the description of command line parameters).
Now you can kill any process by typing

kill process-pid

This gives the process a signal, whose corresponding action should instruct the process to destroy itself. This may not work always though, in which case running the command

kill -KILL process-id

almost certainly destroys the process. The -KILL parameter, as you should have guessed, changes the signal(we need not go into the exact workings). In fact, you can use the kill command to send any signal to the process(check man), the command is named thus just because the default signal is -TERM (terminate anyone?).

But scrolling through ps -aux listing is certainly no fun, and you would imagine linux provides a better way. It does. pgrep lets you use the awesome grep command to search for processes.

pgrep fire

and it will return all process pids having 'fire' in their name. In my case, it just returns the pid of firefox. Now you can use pid and pass signals to it with kill.

I would like to wrap up now. An important segment we have left out are background/foreground processes. I hope to cover those soon. Until then, attain familiarity with everything here, use internet and man pages to read more about everything I have mentioned in bold.

Thanks for reading!

Searching for files at the command line

Locating files on a system is one of the most basic operations users wish to perform. There are three primary tools which you generally use to accomplish this in linux - find, locate and grep.

Regular Expressions
Before we progress, one should at least be familiar with the concept of regular expressions. Basically, it is a representation language for strings. For example "Tom" represents a single specific string. What if we want to represent both "Tom" and "Tod" at the same time? RE enable us to just use the expression "To[md]" to mean either of them. The square brackets mean any one of 'm' or 'd'. It is immediately apparent why this is useful. You can run a command for a multitude of strings with just one go. There are scores of tutorials online for learning RE. Though are not essential at the beginner level, but you would do well to start picking it up in small steps as you progress to a power user.

Find
Find can be used to search for any filename(including RE syntax) under a given directory. The syntax is :

find /directory/path -name filename

Linux commands tend to have a lot of customizations possible. To maintain sanity, it is best to get familiar with just a few useful features and improvise. If you don't provide any directory-path, the current-directory is defaulted, which is convenient.

Locate
Locate is as simple as:

locate filename

This is blindingly fast, but a drawback is that you can't specify a directory specific search, the results are presented from all over your file-system. Actually, locate builds up an index of the whole system(in background), so it can shoot results quickly. It might miss out some files if they have been recently generated. In order to include them, you need to update its database:

sudo updatedb

This database updating facility also doubles as a new-database creation system, which can be used to enable directory specific searches!! For ex.
I want to be able to search for files limited to my home directory. I run the command

sudo updatedb --database-root ~/ -o ~/homedb.db

This creates a new database by the name of homedb.db in the root(~/) directory. Now while running searches, I can ask locate to use this file instead of its default:

locate --database homedb.db filename

And we are done! However, the flexibility of this arrangement is limited, as we need a database file for every folder we want to localise search in. Better to limit this to some of your important directories, and use the find command elsewhere.

For ease of use, I have added 2 aliases to my ~/.bashrc file for searching within home, so that I don't need to type the long-ish commands everytime:

alias hlocate='locate --database ~/homedb.db'
alias hupdatedb='sudo updatedb --database-root ~/ -o ~/homedb.db'

Grep
Finally we reach grep. This is one of the most iconic commands of unix, and the real power of it resides in the use of Regular expressions. However, even without, it is a terribly useful tool.

It won't be always that you know the exact file you are looking for. Typical example of this includes when you are programming and wish to search that in which files you have used a particular function. Grep is hand-crafted for these tasks. Give it an expression, and it will search for it in all the files within the search-path, and give you the files along with the line numbers where the expression occurs. Ex:

grep -r 'main()' *.cpp

This will search in all your .cpp files(in the current directory) for the main() function, and give you the results.

Now we have discussed the grep, locate and find commands for searching for a file, and can see the power of the linux command line. We also saw the advantages and disadvantages of the specific tools and identified the situations where each is best suited. Familiar in the broad sense, now you can quickly broach the man-pages for any specific feature you require at any time.