May 9, 2007

“more” displays the named file(s) one screenful at a time. Simple enough and quite useful – but it’s got a few handy little features I was unaware of prior to getting to more in Linux in a Nutshell.

The straight-forward usage is something like:

$ more file.txt

The result of this will be the first screenful of file.txt with a prompt indicating what percentage of the file was being displayed.Up to today that was the extent of how I used more.

Usually when I’m using more I’m looking for something but I’m not necessarily sure what so grep isn’t what I want. But I’ve often got a pretty decent idea of what I want – perhaps a keyword.

more supports jumping right to the first instance of the pattern you care about. If more is already running you can enter:

/pattern

And more will skip forward to the next instance of the pattern string. This can also be done upon invoking more using the command line syntax:

$ more +/pattern file.txt

If the pattern is found more will present the first match on the displayed screenful. If the pattern is not found more will indicate as much.

Now that you are at the first pattern match perhaps it was not the one you wanted. You can skip to the next match by hitting ‘n’ at the prompt. This is a great way to skip forward in the file quickly. If can skip more than one by typing a number before hitting ‘n’. For example at the more prompt if you type “12n” it will take you to the twelfth instance of the repeated pattern match.

Finally you can work with multiple files in more. The commands for moving between the files are “:n” to move the next file and “:p” to move to the previous. To help keep track of where you are you can use “:f” to display the file name and currently displayed line number.

May 6, 2007

In the last couple of posts I’ve looked at how I can get the information I used to get from Windows Task Manager – CPU, memory, process stats and also how I can get disk information. Basically the commands I need to get a snapshot of my general system health.

Today I’m looking at a command to tell me how much disk space I have available on any given partition. The command to do this (or one of the many, I’m sure) is “df”.

Run without any arguments it reports the amount of free disk space on all mount file systems.

“-t” and “-x” can be used to include or exclude file systems of a specific type (respectively). “-i” provides information on inodes. “-l” only returns local file systems (since all of mine are local this does not create an interesting demo).

There are a few other options but this tool provides the answer to the basic question “how much disk space is available?”

May 5, 2007

Top provides information about the processes currently running sorted by their CPU usage. Like Windows Task Manager it refreshes frequently and gives basic stats on CPU and memory usage. Another similarity is that it can be used to adjust process priority, sort by other criteria (pid, etc), etc.

May 2, 2007

This one is pretty cool – fuser identifies the process id of any processes that are using a specific file or filesystem. This is something I need frequently on Windows when debugging service or multi-user tests. Invariably there will be a race condition that is causing cleanup to not succeed because the cleanup thread has gotten ahead of the app or test thread(s). When that happens the cleanup thread is unable to move or delete log files, temp data, etc.

I’m left wondering who had the file open. There are many ways to find this but I normally use a SysInternals tool to check which process has the open handle. Problem is this isn’t easy to automate so by the time I’m looking for the file lock it’s already gone.

Using fuser I can add this functionality right into my test suites.

To test fuser I performed a more operation on a file in my home directory and left the more process blocked with the file open. That command was:

username@desktop:~$ more menu.lst

In another terminal window I then executed:

username@desktop:~$ fuser -u menu.lst
menu.lst: 5829(username)

So process 5829 being run by the user “username” has the file menu.lst open.

Now I can use ps to figure out what command that user is running (and on what tty).

May 1, 2007

To kick off the “Command of the Day” series I decided to start with addr2line.

Addr2line, part of GNU Binutils, will translate a hex address into the appropriate filename and line number for the code at that address. So an example usage would be if a program crashes at a specific location you can easily find out which line of code in which file the crash occurred at. This is quite useful if you get the crash report via an email or forum post and don’t have access to a core dump or the ability to hook up a debugger (assuming the other person is running a well known pre-built binary and have proper debug symbols).

When compiled (gcc a2ltest.c -ggdb) the produced executable (a.out) prints out the pointer to the function test_method in hex format. An example run is:

..@desktop:~/cotd/addr2line$ ./a.out

0x8048374

Now I can pipe that output to addr2line and see the expected results:

..@desktop:~/cotd/addr2line$ ./a.out | addr2line

/home/../cotd/addr2line/addr2line.c:3

On Windows I could get similar info from various methods such as using map files (though you have to work through the relative addresses on your own and hope that the assembly loaded where you think it did)