printf("Totally out of ideas.\n");

Change GDM login background image on OpenSUSE 11.4

2011-05-03T17:31:00.000-07:00

First, let me start off by saying I truly dislike Gnome, and the attitude by the Gnome devs that somehow giving people options is a bad thing. Why is it that I cannot easily change the background image of the Gnome login screen? Why do I have to use hacks like this one? Why do the hacks always have to change? Anyway, for Gnome 2.32.1 which shipped with OpenSUSE 11.4 the way to change the login background image is like this:

As root:

mv your_new_image.jpg /usr/share/pixmaps/backgrounds/gnome/background-default.jpg

Where your_new_image.jpg is the image you want to be the new background image.

Cygwin top

2011-04-16T11:56:00.001-07:00

If you want to use top in Cygwin, you will need to install the procps package. I have spoken.

W3 CSS3 validation

2011-04-15T19:25:00.000-07:00

I was fiddling around with some text-shadow stuff (which is part of the CSS3 draft) on the gdb tutorial. When I validated the CSS at W3C, I noticed that the validator, by default, chooses CSS level 2.1 instead of CSS level 3. You can manually select CSS3 in the drop down menu here, but I want to be able to click on the link from each of my pages. After all, the reason I have the valid HTML5 and CSS images on every page is to have a handy way to validate each one quickly and easily. Anyway, the fix is pretty simple, which I found in this post. Change the link for the CSS validator to this:

http://jigsaw.w3.org/css-validator/check/referer?profile=css3

The part you need to add is in red.

Getting TweetDeck (Adobe Air) to use your default browser in Gnome

2011-02-05T16:06:00.000-08:00

This has been a bit of an issue in the past. See this lifehacker article, which was inspired by Roy Tanck's blog post. Currently, I am using Adobe Air 2.5.1 on OpenSUSE 11.3 - i386 (Yes, I have a crappy Atom powered net book). Every time I would open a link in TweetDeck, it would open in Firefox rather than Chromium. To make matters worse, the place in Chromium where I could set it as the default browser, the button is grayed out, and it says "Chromium cannot determine or set the default browser." Bummer. But fear not, as the solution is somewhat simple. If you have the "custom menu bar" (not the default one which ships with OpenSUSE) you can do System->System->Preferred Applications, and change the default browser there. Alternatively, you could run "gnome-default-applications-properties" in your shell to get the dialogue box opened up. Once I got it open, on the "Internet" tab, I dropped down the menu under "Web Browser" and selected "Custom". Then I put in /usr/bin/Chromium. You would obviously replace that command with the browser you want to use. And that's it! I didn't even have to restart TweetDeck. It just worked from there on out.

How to change Epiphany default search from Google to DuckDuckGo (Gnome)

2011-01-02T18:40:00.000-08:00

I have been playing around with two new toys lately: The Epiphany web browser, and DuckDuckGo search. I might write more on these another time, but for now I want to show you how you can change the default setting for search (in Epiphany) from Google to DuckDuckGo, by using gconf-editor in Gnome:

Fire up a shell, and enter:

gconf-editor

A dialogue box will pop up. Click on apps -> epiphany -> general

You will see a list of things on the right. Scroll down until you see 'url_search'. Click that, then right click, and select 'edit key'. In the new dialogue box that comes up, paste the following into the 'Value' field:

http://duckduckgo.com/?q=%s&ie=UTF-8&oe=UTF-8

Click, 'OK', and then close gconf-editor. Now when you open up Epiphany and do a search, you should be looking at a result page from DDG, instead of Google.

Happy DDG'ing!

Humorous AMD Video

2011-01-02T06:09:00.000-08:00

With CES looming, and news of AMD winning the International CES Innovations 2011 Design and Engineering Award for its Fusion APU, I have to say I am pretty excited to see Fusion finally coming to fruition. Anyway, since Fusion is upon us, here is a funny new promotional video from AMD about fusion; watch for AMD President & CEO Dirk Meyer at the end:

GDB Tutorial

2010-12-21T21:33:00.000-08:00

As far as GDB tutorials go, I think that Peter Salzman had one of the best. Unfortunately, he let his site go down some time in 2008. Now there is a site which has resurrected his old body of work - Using The GNU GDB Debugger. It is essentially the same as it was, with some bits reorganized. It looks pretty good. Check it out!

Comparison of four Unix pgrep utilities

2010-12-18T15:02:00.000-08:00

Recently I was writing a script to kill programs by name; I admit this to my embarrassment, for although it was a nice learning experience in terms of shell programming skills, it was a complete reinventing of the wheel. And not even a good wheel - more like a flat tire. I can say this, because I am comparing my work to the standard Unix pgrep(1) utility. At any rate, as I was studying the FreeBSD and Linux man pages for pgrep, I found it somewhat difficult to get the big picture regarding what options were available in both versions. To the end of clarifying matters, I compiled a table which compares all of the switches for the FreeBSD, Linux, Solaris 10, and HP-UX 11i versions of pgrep. I added the HP-UX column at the request of a friend, who also asked for a column with the AIX options. Unfortunately, I was not able to locate a man page for pgrep on the AIX system. It seems to me that pgrep may not ship as a part of the standard AIX distribution. It's too bad that I don't have access to an AIX machine, as I would implement a version on that system.

How to build Dillo on OpenSUSE 11.3

2010-12-18T12:56:00.000-08:00

Dillo is a small, fast, and light browser. In order to build it on OpenSUSE, you will need some pre-requisites. This article will cover how to get the source code for Dillo (and associated libraries), as well as the software build tools you will use to compile the Dillo browser.
First, open a terminal, and make yourself a work directory, and cd into it: (Note that the dollar sign '$' indicates a shell prompt, so you don't type that part in)

 $ cd tmp
$ mkdir build
$ cd build

Then the you will want to get the source for dillo. You will also need to get the source for FLTK2.

Iin your terminal, do:

$ wget -c http://www.dillo.org/download/dillo-2.2.tar.bz2

You should now have a copy of dillo-2.2.tar.bz2

Now do:

$ wget -c http://ftp.funet.fi/pub/mirrors/ftp.easysw.com/pub/fltk/snapshots/fltk-2.0.x-r7725.tar.bz2

When the download is completed, you will have the FLTK2 bzip file. Unpack them:

$ tar -xvjf dillo-2.2.tar.bz2

When that is finished, do:

tar -xvjf fltk-2.0.x-r7725.tar.bz2

At this point you should have a directory for dillo, and one for FLTK2:

$ ls
$ dillo-2.2  dillo-2.2.tar.bz2
fltk-2.0.x-r7725  fltk-2.0.x-r7725.tar.bz2

Change directory into the fltk-2.0 directory (We need to build that first)

$ cd fltk-2.0.x-r7725/

Before we do anything else, we need to install some tools, or you will never be able to build the source. In the terminal, first change to root (su root) then

$ zypper install gcc gcc-c++ autoconf automake make flex bison libjpeg-devel libpng14-devel zlib-devel Mesa Mesa-devel xorg-X11-devel

It will ask you if you want to install these things - it might recommend other things - just hit 'y' and enter.

Once the tools are installed, you can hit ctrl-d to drop back down to your regular user account. Now we are ready to build. If you have more than one processor, the make utility can use them all. Even if you have only a single core machine, you can still tell make to use "two" versions of itself. For every core you have available, do a number one higher than that. So for example with a dual core, do make -j3, on a quad core, do make -j5 and so on. If you have a single core machine, do:

$ make -j2

If you have a fast quad core system, it should take less than a minute. If you have a single core machine, it will take considerably longer. Once the build is done (it should end with something like this - with no error messages

Linking timer...
Linking utf...
Linking fullscreen...
Linking valuators...
Linking list...
Linking wizard...
$

Then su into root again, and type

$ make install

If all goes well, you now have a working version of FLTK2. Now we need to build dillo. So, drop back into regular user status by hitting ctrl-d then:

$ cd ../dillo-2.2
$ ./configure

Once again, use the make -j2 (or whichever -j number you used before):

$ make -j2

When it is done building (you get your prompt back, and there are no errors just before it), then su into root one more time, and do:

$ make install-strip

When it is done installing, hit ctrl-d to drop out of root, and you can run dillo by typing dillo in the terminal, and hitting enter. That's it - you are done! Enjoy the blazing fast speed of dillo!

How to change Gnome login background image.

2010-11-28T08:59:00.000-08:00

Update: For OpenSUSE 11.4, see this post.

As root, enter the following into your shell:

gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults \
  --type string \
  --set /desktop/gnome/background/picture_filename some_picture_filename.png

Of course you will need to change the bit in red, "some_picture_filename.png" to the one that you want as your background image on the login screen.

It seems that the method for doing this has been evolving. What worked even six months ago does not appear to work now. As of this writing, I am using Gnome 2.30.0 with OpenSUSE. I found the information here.

Excellent AMD Bulldozer Blog

2010-11-06T06:48:00.000-07:00

Many of us have been patiently waiting for the release of the AMD Bulldozer processor. As the date draws nearer, more details about the chip are starting to emerge. Today I came across this interesting blog, Patent based research regarding AMD's future MPUs. The title gives a little idea of what the blog is about, but keep in mind that there is more there than patent research. Indeed, there is a lot of info there. The author also comments on the AMD Llano and Bobcat processors. Check it out for yourself!

Misconceptions

2010-09-14T17:37:00.000-07:00

Last night I was fiddling around with some really simple code; the object of my program was to test a positive integer, to see if it was odd or even, and then print the result. There is more than one way to do this, some being more expensive than others. I thought I would run some tests to see what sort of differences, with regard to program execution time, I could come up with. I had three methods of checking for whether a number was odd or even. The first one uses the venerable modulus operator (%), as displayed below:

mod.c

#include <stdio.h>
#include <limits.h>

int main(void)
{
    int i;

    for (i = 0; i < INT_MAX; ++i) {
        if (i % 2 == 0) {
            printf("%d is even.\n", i);
        } else {
            printf("%d is odd.\n", i);
        }
    }

   return 0;
}

Next, I tried a bit mask. Basically, all it does is bitwise and (&) the first bit of the integer and 1:

bit.c

#include <stdio.h>
#include <limits.h>

int main(void)
{
    register int i;

    for (i = 0; i < INT_MAX; ++i) {
        if (i & 1) {
            printf("%d is even.\n", i);
        } else {
            printf("%d is odd.\n", i);
        }
    }

    return 0;
}

Finally, I exploited the fact the integer division truncates any remainder of a number:

int.c

#include <stdio.h>
#include <limits.h>

int main(void)
{
    register int i;

    for (i = 0; i < INT_MAX; ++i) {
        if ((i / 2) * 2 == i) {
            printf("%d is even.\n", i);
        } else {
            printf("%d is odd.\n", i);
        }
    }

    return 0;
}

I compiled each one with gcc -O2, and these were my times:

time ./mod > /dev/null
./mod > /dev/null  299.43s user 1.34s system 62% cpu 8:02.40 total

time ./bit > /dev/null
./bit > /dev/null  298.97s user 1.87s system 83% cpu 5:59.71 total

time ./int > /dev/null
./int > /dev/null  304.14s user 1.57s system 61% cpu 8:16.85 total

These times are not all that useful, as each program did not get the same amount of cpu. Things got a little more interesting though when I recompiled with gcc -O3, and made sure the programs could each get pretty much all of the cpu for the entirety of their run times:

time ./mod > /dev/null         
./mod > /dev/null  296.04s user 1.00s system 99% cpu 4:58.53 total

time ./int > /dev/null
./int > /dev/null  297.81s user 1.04s system 99% cpu 5:00.46 total

time ./bit > /dev/null         
./bit > /dev/null  292.43s user 1.16s system 99% cpu 4:54.79 total

Really not much difference in time at all between the three - they all took around five minutes. Without looking at the assembly for each program, these results might seem a little surprising, especially for mod.c, and bit.c. But look at the assembly for the two (and you won't be surprised about the execution time any longer):

.file   "mod.c"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC0:
        .string "%d is even.\n"
.LC1:
        .string "%d is odd.\n"
        .text
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB11:
        .cfi_startproc
        pushq   %rbx
        .cfi_def_cfa_offset 16
        xorl    %ebx, %ebx
        .cfi_offset 3, -16
        jmp     .L4
        .p2align 4,,10
        .p2align 3
.L8:
        movl    %ebx, %esi
        xorl    %eax, %eax
        movl    $.LC0, %edi
        addl    $1, %ebx
        call    printf
        cmpl    $2147483647, %ebx
        je      .L7
.L4:
        testb   $1, %bl
        je      .L8
        movl    %ebx, %esi
        xorl    %eax, %eax
        movl    $.LC1, %edi
        addl    $1, %ebx
        call    printf
        cmpl    $2147483647, %ebx
        jne     .L4
.L7:
        xorl    %eax, %eax
        popq    %rbx
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE11:
        .size   main, .-main
        .ident  "GCC: (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]"
        .section        .comment.SUSE.OPTs,"MS",@progbits,1
        .string "Ospwg"
        .section        .note.GNU-stack,"",@progbits

And bit.c:

.file   "bit.c"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC0:
        .string "%d is even.\n"
.LC1:
        .string "%d is odd.\n"
        .text
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB11:
        .cfi_startproc
        pushq   %rbx
        .cfi_def_cfa_offset 16
        xorl    %ebx, %ebx
        .cfi_offset 3, -16
        jmp     .L4
        .p2align 4,,10
        .p2align 3
.L8:
        movl    %ebx, %esi
        xorl    %eax, %eax
        movl    $.LC0, %edi
        addl    $1, %ebx
        call    printf
        cmpl    $2147483647, %ebx
        je      .L7
.L4:
        testb   $1, %bl
        jne     .L8
        movl    %ebx, %esi
        xorl    %eax, %eax
        movl    $.LC1, %edi
        addl    $1, %ebx
        call    printf
        cmpl    $2147483647, %ebx
        jne     .L4
.L7:
        xorl    %eax, %eax
        popq    %rbx
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE11:
        .size   main, .-main
        .ident  "GCC: (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]"
        .section        .comment.SUSE.OPTs,"MS",@progbits,1
        .string "Ospwg"
        .section        .note.GNU-stack,"",@progbits

They are virtually identical; the compiler turned them into almost the same program! In case you have trouble seeing where the differences lie, here is the diff for the two:

diff mod.s bit.s
1c1
<       .file   "mod.c"
---
>       .file   "bit.c"
31c31
<       je      .L8
---
>       jne     .L8

You don't get much closer than that. I won't bother posting the assembly for int.c, (its just a couple more instructions) as the difference in run time is negligible. With a good optimizing compiler, what you wrote might not even end up in the final output.

encrypt(3) example usage

2010-08-22T09:52:00.000-07:00

A while back I had someone ask about how to use the encrypt() function under Linux. He had tried the man page, encrypt(3), which even contains an example usage. Unfortunately for him, the example given was terribly broken. I managed to find a post by Jens Thoms Törring which contained a working sample (though there was an off-by-one error which Mr. Törring later brought to my attention). Since the current man page at the time had a broken example, I thought I would send a patch in to have it fixed. That was a little over a year ago, but guess what? Still the same broken code! I don't know why the patch was not applied. Perhaps it was a crappy patch (I don't normally do patches, so I might have done it wrong). Or maybe the maintainer of the man pages was too busy. I don't really know what happened. Since speculation is pretty much useless, I thought I might post the code here, for anyone else searching for a useful example of encrypt usage.

/* Modified from original source code
 * written by Jens Thoms Toerring.  The original
 * can be found on comp.os.linux.development.
 */

#define _XOPEN_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <crypt.h>

/* You need to link with libcrypt (-lcrypt) 
 * to compile this example with glibc.
 */

int main(void)
{
    char key[64];
    char orig[9] = "eggplant";
    char buf[64];
    char txt[9];
    int i, j;

    for (i = 0; i < 64; i++) {
        key[i] = rand() & 1;
    }

    for (i = 0; i < 8; i++) {
        for (j = 0; j < 8; j++) {
            buf[i * 8 + j] = orig[i] >> j & 1;
        }
        setkey(key);
    }
    printf("Before encrypting: %s\n", orig);

    encrypt(buf, 0);
    for (i = 0; i < 8; i++) {
        for (j = 0, txt[i] = '\0'; j < 8; j++) {
            txt[i] |= buf[i * 8 + j] << j;
        }
        txt[8] = '\0';
    }
    printf("After encrypting:  %s\n", txt);

    encrypt(buf, 1);
    for (i = 0; i < 8; i++) {
        for (j = 0, txt[i] = '\0'; j < 8; j++) {
            txt[i] |= buf[i * 8 + j] << j;
        }
        txt[8] = '\0';
    }
    printf("After decrypting:  %s\n", txt);

    return 0;
}

The easy way out

2010-08-21T15:41:00.000-07:00

I was just reading an article by Andrei Alexandrescu called, The Case for D. In it he compares the traditional C "hello world" program to its D counterpart. Consider the following example:

#include <stdio.h>



main()

{

    printf("Hello, world\n");

}

If I compile this with gcc -o hello hello.c, I get an executable (without any warnings from the compiler). It runs, and the return value is 13. Wha-what? Return value? I didn't return anything. But printf() did.

~/stuff> ./hello

Hello, world

~/stuff> echo $?

13

See? The thirteen happens to be the return value of printf() - 13 characters in "Hello, world\n" got printed out to the console. This sticks around for the shell echo, because status did not get returned back to the OS, via a return statement. The above program is not exactly conforming C - not to C89, and not to C99. In C89, main may be declared as above, but must have an explicit return statement. Under C99, main must be declared as one of the following:

int main(void)

int main(int argc, char *argv[]) /* int main(int argc, char **argv)

                             * is also acceptable

                             */

Additionally, under C89, an explicit return at the end of main is required. In C99, it is not, and if not provided, a return value of zero is implied.

Andrei Alexandrescu argues that this all creates incorrect behaviour. If we do the classic hello world program, such as the first example¹, then a weird value gets returned from main. That is not really desirable at all. If we add a return (under C89), or if one is implied (C99), we get rid of the weird values being sent back to the OS. This appears to fix the problem. Or does it?

What happens if printf() fails? It returns a negative value. Do we let printf() happily fail, and then return 0 (which means success on most systems)? That does not make sense either. His suggestion was an altered "hello world" program:

#include <stdio.h>



int main(void)

{

    return printf("Hello, world!\n") < 0;

}

This might even make an experienced C programmer do a double take. For those who may not get what it is doing, basically the return value of printf() is evaluated and compared to 0. If it is less than 0 (meaning printf() failed, and returned a negative value), then the expression is true (remember that in C, the result of any expression evaluating to true is non-zero). Because it is true, non-zero then gets returned from main. If the return from printf() is not less than zero (meaning it succeeded, and returned the number of characters printed), then the expression is false. All expressions evaluating as false are 0. So if printf() is successful, the expression evaluates as false, and the result of the expression is 0, which gets returned from main. In short, if the call to printf() fails, the proper value (i.e., not 0) is returned, indicating some sort of failure to the OS. If the call to printf() succeeds, the integer 0, indicating all is well, is returned. This is, in my opinion, a truly elegant bit of code.

At any rate, the point of this one part of his article is not to talk about how to fix C, but that using D is the preferred option, because, it does things more correctly. According to Alexandrescu,

"D attempts not only to allow you to do the right thing, it systematically attempts to make the right thing synonymous to the path of least resistance whenever possible. And it turns out they can be synonymous more often than one might think."

From what I can glean from the article, I find myself having to agree. I mean, the "right thing" for C is to check those return values. But this is not _at all_ the path of least resistance. His modified example is for the simplest bit of code. A less refined approach might look something like this:

#include <stdio.h>

#include <string.h>

#include <stdlib.h>



int main(void)

{

    char message[] = "Hello, world\n";

    size_t message_len;



    message_len = strlen(message);

    if (printf("%s", message) != (int) message_len) {

        fprintf(stderr, "%s\n", "Call to printf() failed!");

        exit(EXIT_FAILURE);

    }



    return 0;

}

As you can see it gets real ugly - real fast. Furthermore, while it might deal with one problem, it also causes another: If we are to check the return values of all functions, then we must also deal with the call to fprintf() (I will leave that as an exercise to the reader). All of this for one of the most simple programs you can do! The point is that while we don't have to go to these lengths for a simple "hello world" program (recall the elegant example by Alexandrescu), we do have to address these issues in production code. In truth, it often seems easier to ignore some things than to deal with them. But this will come back to bite you like a rabid dog. Wouldn't it be nice if some of this stuff was covered by the language so that you, the programmer, could get on with writing good code? I think that D just might be headed in that direction.

1. I believe the example given is straight out of K&R, albeit from the initial introductory/tutorial material of the text. Returning a value from main is explained in more detail further on in the book.

Google Go, or Digital Mars D?

2010-08-21T14:03:00.001-07:00

Recently I learned of the Go programming language. It is, according to the header on the main golang web page, an expressive, concurrent, garbage-collected, systems programming language. It looks kind of cool. There is a compiler (6g) which works on my system. I would prefer to use the gcc front-end (gccgo), but at this point I cannot get it running.

Then there is the D programming language. It is, according to the D main page, also a systems programming language. It looks appealing as well. D comes with its own compiler, dmd, and a front end for gcc (gdc).

Apparently, it kind of seems that these two languages have some overlap in their audience/goals. This thread has some discussion about that from a primarily pro D perspective. This is another thread, but more from a pro Go perspective.

My dilemma is that I want to learn a new language. I am a hobby programmer, with a pretty good handle on C. I have made stabs at C++ before, and while I think it is a wonderful language (string handling and memory management are so much easier than C) it is also a lot more to learn than C. I am wondering if D or Go might be more suitable. Ultimately, I might have to dive into both to make my decision. I am hoping not to have to do that though. One thing that will help make my decision is the documentation available. I cannot learn a new language without some help. So I will have to look into that aspect as well. If you are a Go programmer, or a D programmer, (or both) and you feel like offering any suggestions as to what path I should take, please leave a comment. I would appreciate any sound advice.

More on changing the Gnome clock

2010-05-01T10:20:00.000-07:00

In my previous post about the Gnome clock, I showed you how to change the clock from the default 24 hour time display to a 12 hour format. In this post, I will show how you can change things to display seconds as well. Here is my default display string in gconf-editor:

%a %b %d, %l:%M %p

From reading the date manpage, you know that this will display the Year, month, day, hours and minutes. Something like this: Sat May 01, 5:16. But what about seconds? If you want that, just add the appropriate specifier (%S) to the date string:

%a %b %d, %l:%M:%S %p

Note: You will also need to check the 'show_seconds' box roughly 11 places below the date string setting in gconf-editor. If you forget this part, the seconds portion will display, but the numbers will not actually change until the minutes portion changes because the clock isn't being updated every second.

What I have been doing.

2010-04-24T11:13:00.000-07:00

For the past few minutes, anyway...

(a+b)^7
= (a+b)(a+b)(a+b)(a+b)(a+b)(a+b)(a+b)
= (a^2 + ab + ab + b^2)(a+b)(a+b)(a+b)(a+b)(a+b)
= a(a^2 + ab + ab + b^2) + b(a^2 + ab + ab + b^2)(a+b)(a+b)(a+b)(a+b)
= a^3 + a^2b + a^2b + ab^2 + a^2b + ab^2 + ab^2 + b^3 (a+b)(a+b)(a+b)(a+b)
= (a^3 + 3a^2b + 3ab^2 + b^3)(a+b)(a+b)(a+b)(a+b)
= a(a^3 + 3a^2b + 3ab^2 + b^3) + b(a^3 + 3a^2b + 3ab^2 + b^3)(a+b)(a+b)(a+b)
= (a^4 + 3a^3b + 3a^2b^2 + ab^3 + a^3b + 3a^2b^2 + 3ab^3 + b^4)(a+b)(a+b)(a+b)
= (a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4)(a+b)(a+b)(a+b)
= a(a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4) + b(a^4 + 4a^3b + 6a^2b^2 + 4ab^3 + b^4)(a+b)(a+b)
= (a^5 + 4a^4b + 6a^3b^2 + 4a^2b^3 + ab^4 + a^4b + 4a^3^b2 + 6a^2b^3 + 4ab^4 + b^5)(a+b)(a+b)
= (a^5 + 5a^4b + 10a^3b^2 + 10a^2b^3 + 5ab^4 + b^5)(a+b)(a+b)
= a(a^5 + 5a^4b + 10a^3b^2 + 10a^2b^3 + 5ab^4 + b^5) + b(a^5 + 5a^4b + 10a^3b^2 + 10a^2b^3 + 5ab^4 + b^5)(a+b)
= (a^6 + 5a^5b + 10a^4b^2 +10a^3b^3 + 5a^2b^4 + ab^5 + a^5b + 5a^4b^2 + 10a^3b^3 + 10a^2b^4 + 5ab^5 + b^6)(a+b)
= (a^6 + 6a^5b + 15a^4b^2 + 20a^3b^3 + 15a^2b^4 + 6ab^5 + b^6)(a+b)
= a(a^6 + 6a^5b + 15a^4b^2 + 20a^3b^3 + 15a^2b^4 + 6ab^5 + b^6) + b(a^6 + 6a^5b + 15a^4b^2 + 20a^3b^3 + 15a^2b^4 + 6ab^5 + b^6)
= a^7 + 6a^6b + 15a^5b^2 + 20a^4b^3 + 15a^3b^4 + 6a^2b^5 + a^6b + a^6b^2 + 6a^5b^2 + 15a^4b^3 + 20a^3b^4 + 15a^2b^5 + 6ab^6 + b^7
= a^7 + 7a^6b + 21a^5b^2 + 35a^4b^3 + 35a^3b^4 + 21a^2b^5 + 7ab^6 + b^7

OpenSUSE 11.2: My best Linux experience by far.

2010-02-06T16:23:00.000-08:00

Over the years I have been through a few different Linux distributions. I ran Mandrake (hey, I was really a n00b) for a bit. Then I caught the Gentoo bug (no, I was not a ricer, but I did really like their helpful forums and wiki pages) and did that for quite a few years. Then something went wrong with my system, and I lost the drive. I didn't have time to fiddle with restoring everything, so I slapped Fedora 11 on it. It was the Fedora install that got me thinking that I kind of enjoyed it when everything seemed to work, right out of the box. In fact, I was so pleased with the way it all worked so well, that I installed it on both of my computers. I liked the fact that I didn't have to spend hours trying to make things work. Someone once said, "Linux is only free if your time is worth nothing." Stated by someone embittered against Linux, to be sure, but there is a grain of truth there. I want to do my work -- NOT fight with getting things working. Fedora was showing me that this could happen. But there were a few things I was not happy with, so I started thinking about a different distro. I decided to try OpenSUSE, and boy am I ever glad I did. Say what you will about Novell being in bed with Microsoft, but they have put together one heck of a distribution. Hence, the reason for this post.

I recently bought a new box store computer. Nothing fancy, but a better processor that the old one that just kacked on me. I put OpenSUSE 11.2 on it, and everything worked correctly. Just turn it on, and it works. Now I also got Windows 7 with the new machine. When I went to install Dragon Naturally Speaking, I was informed that the onboard sound on my machine was not suitable. No problem, as I have an old Creative SoundBlaster X-FI card to put in it. (Of course this card has history with Linux, and none of it good. More about that later). I installed it today and, after a bit of prodding, Windows 7 found the right drivers and installed them. Presto - sound card working nicely. Now I mention this because when I was playing around with the beta and RC versions of Win 7, I was very impressed with the facilities for finding and installing drivers. Microsoft has done well with this. Because of my previous experience, I was little surprised that the driver installation was not a little smoother today. So much for Windows, but what about Linux?

To be honest, I was hopeful my experience would be better this time than previous attempts. Creative has not been kind to the Linux community with its X-FI cards. They have offered zero support for the longest time. Apparently they have changed their ways a little, and now there is reasonable support for that line of cards. While OpenSUSE was booting up, I was thinking I would probably have to fire up YAST, and do something to get the card installed, but before I did that, I figured I might as well see if there was any sound. I fired up GnR, and I was completely blown away. The sound worked. Immediately. Without any intervention by me. Even Windows 7 (which I am by no means bashing here) did not do this.

To any and all OpenSUSE people who happen to read this: Thank you. Thank you for making my Linux Experience so pleasant. I am long tired of fighting with things that should just work. You have made the Linux that I have been waiting for a reality.

Changing Gnome panel clock from 24hr time to 12hr time on OpenSUSE 11.2

2010-01-28T09:23:00.000-08:00

Fire up your shell, and type in gconf-editor. Then, on the left, select Apps --> panel --> applets --> applet0 --> prefs (This was slightly different for me between two different machines. It might be ...applets --> clock_screen0 --> prefs.) First you want to right click on 'format' on the right side of the gconf-editor, and select 'Edit Key'. In the dialogue box that comes up, enter 'custom' (without the quotes). Then click ok. Next, you will need to enter 'custom_format' (about 6 entries above 'format'). Again, right click and select 'Edit Key'. Here you will enter <b>%a %b %d, %l:M %p</b> and click ok. This will get you a format such as Thu Jan 28, 12:20. If you prefer a different format, look at some of the options available in the date man page.

Read more here. (Don't forget to look at the comments section at the bottom as well).

Shell shortcuts part deux.

2010-01-18T12:28:00.000-08:00

In my last post, I demonstrated how you can use the !! and !$ features of your Bash & zsh history to get your work done more quickly. I use the former all the time, but the latter? Well, not so much. This is because I use something even better for interactive shell use. It is M-. That is Meta plus period. All you Emacs ~~zealots~~ users will know what I mean by Meta. :) The Meta-key is Alt on your computer, or sometimes Esc. Both work on my machine, but I prefer Alt over Esc, because it is less work.

Try doing M-. in your shell (Press and hold the Alt key, and then press the period key). Like !$, M-. will give you the last part of the last command entered, but this time you can see it immediately. Better still, you can cycle through all of your commands. Just keep hitting M-. and the shell will display the last part of each command, in order, from newest to oldest.

Note: If you use the ESC key for your 'Meta' key, then you need to release the ESC key each time. Otherwise, if you hold it down and tap the . (period) key, it will return the end of the last command only once, and then start echoing the period after it.

As an example, say you had just finished a

grep fred /etc/passwd

You are ready to use the command line history feature:

vi M-.

Which would expand to (immediately):

vi /etc/passwd

Then, if it looks right, just press Enter.

Shell shortcuts

2010-01-16T13:22:00.000-08:00

In Bash and zsh, you can access the command history by using several shortcuts. For example, by typing !![Enter], the previous command will be executed. If you are not sure of what the previous command was, you could do !!:p[Enter] and the previous command will be displayed, but not executed. Now, if you like what you see, you can do !![Enter], and the shell will execute that command.

Another ! shortcut is !$. This will give you the end of the previous command. So if my previous command was:

grep fred /etc/passwd

doing !$ would give me /etc/passwd. This can be handy. Say for example the user fred exists on the system, and grep returns his record from /etc/passwd. If there is something I see in one of the fields that I wish to change, all I need to do (provided that grep was the last command I did) is:

vi !$

This will expand to

vi /etc/passwd

If you are not sure how !$ will expand for you (ie., you cannot remember for certain what your last command was exactly), you can use the :p option:

vi !$:p

Pagers

2010-01-15T12:51:00.000-08:00

I won't give you a history of documentation viewers (aka pagers) on *nix systems, other than to say that there used to be pg and more. Then along came less, which was a lot like more, but way better. Apparently there is a play on words there, so maybe it is true that less is more.

Anyway, I have long followed the advice to use the less pager where it is available. I don't follow that advice strictly any more. I now use most. From the most home page:

"MOST is a powerful paging program for Unix, VMS, MSDOS, and win32 systems. Unlike other well-known paging programs most supports multiple windows and can scroll left and right. Why settle for less?"

Indeed.

Making your Bash scripts look a little better

2010-01-14T16:31:00.000-08:00

One thing I have noticed about this blog is that shell scripts are _very_ difficult to make look nice. I am not sure if that is a Blogger problem, or an issue with this template. Either way, I don't like mucking around with the way things look. I want to get my ideas down and not have to be constantly tweaking the text formatting.

Anyway, after monkeying around for a while with the shell script on the previous post, I decided to search for a script beautifier, along the lines of GNU indent, but for shell scripts. Eventually, I came across a ruby script, written by Paul Lutus, and aptly named Bash Script Beautifier. So far, it has worked very well for me.

As always, utilities such as this one may not work exactly the way you want. You would do well to make a backup copy of your script before you run it through the beautifier. Also, be sure to read the documentation on the download page. You can read all about it, and download the script here.

Optimizing your shell scripts

2010-01-12T14:56:00.000-08:00

A few days ago I came across a couple of posts, by Brock Noland, about splitting strings natively with the shell. You can find them here and here. Basically, the writer demonstrated that using shell builtins and variables is much more desirable than using outside programs, such as cut and awk for the same purpose. The reason for this is due to speed. Every time you make a call to an outside program with the shell, you fork a new process, and that takes time.

I decided to tinker with this idea a bit more, to get a better impression of how much slower using cut and awk really is. I made each of the following functions iterate 100 times. I am pretty sure some of you will be shocked by the speed difference between cut and awk, versus the shell native string splitting.
Here is my code, followed by the execution results:

Note: The following code is virtually identical to what is found on the pages I linked to above. The first two functions I modified to iterate more times, the third and fourth are essentially unchanged, and the final two are changed from the two preceding, albeit slightly, to gain a small performance increase.

#!/bin/bash                                  
f_cut() {
   for i in {0..99}; do
      while read line; do
         uid=$(printf "$line" | cut -d: -f3)
         if [[ $uid -gt 10 ]]; then         
            shell=$(printf "$line" | cut -d: -f7)
            if [[ '/sbin/nologin' == "$shell" ]]; then
               printf "$line" | cut -d: -f1           
            fi                                        
         fi                                           
      done </etc/passwd                            
   done                                               
}                                                     

f_awk() {
   for i in {0..99}; do
      while read line; do
         uid=$(printf "$line" | awk -F: '{print $3}')
         if [[ $uid -gt 10 ]]; then                  
            shell=$(printf "$line" | awk -F: '{print $7}')
            if [[ '/sbin/nologin' == "$shell" ]]; then    
               printf "$line" | awk -F: '{print $1}'      
            fi                                            
         fi                                               
      done </etc/passwd                                
   done                                                   
}                                                         

shell_1() {
   for i in {0..99}; do
      while read line; do
         oldifs="$IFS"   
         IFS=:           
         set -- $line    
         IFS="$oldifs"   
         if [[ $3 -gt 10 ]] && [[ '/sbin/nologin' == "$7" ]]; then
            printf "$1"                                           
         fi                                                       
      done </etc/passwd                                        
   done                                                           
}                                                                 

shell_2() {
   for i in {0..99}; do
      while IFS=: read username pp uid gid gecos hd shell; do
         if [[ $uid -gt 10 ]] && [[ '/sbin/nologin' == "$shell" ]]; then
            printf "$username"                                          
         fi                                                             
      done </etc/passwd                                              
   done                                                                 
}                                                                       

shell_3() {
   oldifs="$IFS"
   IFS=:      
   for i in {0..99}; do
      while read line; do
         set -- $line    
         if [[ $3 -gt 10 ]] && [[ '/sbin/nologin' == $7 ]]; then
            printf "$1"                                         
         fi                                                     
      done </etc/passwd                                      
   done                                                         
   IFS="$oldifs"                                                
}                                                               

shell_4() {
   oldifs="$IFS"
   IFS=:
   for i in {0..99}; do
      while read username pp uid gid gecos hd shell; do
         if [[ $uid -gt 10 ]] && [[ '/sbin/nologin' == $shell ]]; then
            printf "$username"
         fi
      done </etc/passwd
   done
   IFS="$oldifs"
}

printf "\n%s" "---Cut---"
time f_cut >/dev/null
printf "\n%s" "---Awk---"
time f_awk >/dev/null
printf "\n%s" "---Shell 1---"
time shell_1 >/dev/null
printf "\n%s" "---Shell 2---"
time shell_2 >/dev/null
printf "\n%s" "---Shell 3---"
time shell_3 >/dev/null
printf "\n%s" "---Shell 4---"
time shell_4 >/dev/null

Now we'll have a look at the time results:



---Cut---
real    1m10.278s
user    0m20.068s
sys     1m9.745s 

---Awk---
real    1m24.043s
user    0m25.170s
sys     1m21.238s

---Shell 1---
real    0m1.387s
user    0m1.282s
sys     0m0.100s

---Shell 2---
real    0m1.219s
user    0m1.109s
sys     0m0.104s

---Shell 3---
real    0m0.943s
user    0m0.852s
sys     0m0.090s

---Shell 4---
real    0m0.887s
user    0m0.786s
sys     0m0.097s

First, notice that the functions with cut and awk took over a minute each to complete the work! Compare this with the results of Shell 1 and Shell 2 and you can see a massive difference. The latter only took a little over a second to complete. The obvious lesson here, as Brock Noland pointed out in his post, is that cut and awk are not the best solution in a case like this.

The last two functions, whose results are displayed in Shell 3 and Shell 4, are my modifications. I was able to shave enough off to get them both below a second in execution time. I did this by moving some stuff out of the for loop that did not need to be in there at all. This saves a tiny bit of work for the processor. On big jobs, this would add up to bigger time differences.

Don't use cut or awk for jobs like this. Let the shell do the work.

Using pushd, popd and dirs

2009-12-28T16:28:00.000-08:00

Since I have a bit of time on my hands, I thought I might share a trick or two. Well, not really 'tricks,' but good information to know. I will cover the shell builtins, pushd, popd, and dirs for bash and zsh. Additionally, I will demonstrate how to use some shell aliases, in order to make the use of these handy builtins even more convenient, and time saving.

Wouldn't it be nice if you could have your shell keep track of the directories where you were, so that you could easily return to them later? If you are using bash or zsh, you already have this capability available to you.

Say you are working in the directory ~/programming/network/modules. You wish to cd to another directory, and then return. There are several ways you could do this, but some are definitely more efficient than others. Consider:

modules $ cd ~/bin
bin $

Now, to get back to the directory ~/programming/network/modules, I hope you would never consider doing this:

bin $ cd ~/programming/network/modules

Of course you could do it that way, but it is such a waste of keystrokes, and of your time. In this case, it is best to do this:

bin $ cd -

The cd - is a short cut to return to the previous directory. It only is useful for one directory though. If you were to issue this command repeatedly, you would flip back and forth between the same two directories.

If you want the shell to remember more directories, you need to use the pushd and popd commands. By using these two, you can utilise the directory stack to keep track of directories you want to. Instead of using cd to change directory, use pushd to both push the current directory name on to the stack, and to change to the new directory you wanted. To return to my previous example, where I was in ~/programming/network/modules, and wanted to change to ~/bin, I would do:

modules $ pushd ~/bin
~/bin ~/programming/network/modules
bin $

Now I am in ~/bin, and the old directory (~/programming/network/modules) is on the stack, saved for future use. If I wanted to return to the previous directory, I would simply do:

bin $ popd
~/programming/network/modules
modules $

Right back where I started! Of course, if you were only changing directory once, you would be better off using cd -, as shown previously. But if you have a great deal of directories you wish to save, push them on to the stack with pushd, and use them later.

How then, do I keep track of where I am at, and what stack frames are available, and where? Consider the following (a contrived example, but good enough as an illustration):

modules $ cd
~ $ pushd programming
~/programming ~
programming $ pushd network/
~/programming/network ~/programming ~
network $ pushd modules/
~/programming/network/modules ~/programming/network ~/programming ~

As you can see, I issued a cd command which, without options or arguments, changed my current working directory to my home directory, ~/. Then I pushed 3 directories on to the stack: ~/programming, ~/network, and ~/modules. If I use the dirs -v command, I can get a listing of the directory stack:

modules $ dirs -v
 0  ~/programming/network/modules
 1  ~/programming/network
 2  ~/programming
 3  ~
modules $

I pushed ~/ on to the stack first, and you can see now that it is on the 'bottom', underneath all the other frames.

You can also use the dirs command with no options, where you will get a listing of the stack frames, but listed on the same line, with the left side corresponding to the most recent push, and the right side being the first push:

modules $ dirs
~/programming/network/modules ~/programming/network ~/programming ~

You can use the info from dirs -v to make directory changes. If I wanted to go to ~/programming rather quickly, I would do:

modules $ pushd +2
~/programming ~ ~/programming/network/modules ~/programming/network
programming $

The +2 corresponds to frame 2 of the dirs -v listing above.

Both pushd and popd can take an integer like the above +2, with either '+' or '-'. If a '+' is specified, +n, then the nth stack frame from the 'top' of the stack (dirs -v, or the 'left' of a dirs listing)' is affected. If a '-' is specified, -n, then the nth frame from the 'bottom of the stack (dirs -v, or the 'right' of a dirs listing) is affected. To confuse things a little here, in the zsh, if setopt PUSHD_MINUS is set, then the function of the '+' and '-' are reversed when used with both pushd and popd.

zsh also has a feature where you can use cd with a +n where n corresponds to a stack frame, and the cd will be to that directory.

[kermit@minty]~/programming/network% pwd
/home/kermit/programming/network
[kermit@minty]~/programming/network% dirs -v 
0       ~/programming/network
1       /bin
2       ~
3       ~/programming
[kermit@minty]~/programming/network% cd +1
/bin
[kermit@minty]/bin% pwd
/bin

This should be enough to give you an idea of what can be accomplished with pushd and popd. If you find yourself using these two commands often, you will begin to long for a shortcut. Place the following in your .bashrc (or .zshrc)

alias -- +='pushd'
alias -- -='popd'

Now you can use + for pushd, and - for popd.

A couple of other thoughts. First of all, if you want to clear your directory stack, do

dirs -c

Regarding dirs, a useful feature of zsh (which bash doesn't have) is the ability to populate the stack 'manually' with a list, using the dirs command:

[kermit@minty]~% pwd
/home/kermit
[kermit@minty]~% dirs -v
0       ~
[kermit@minty]~% dirs ~/programming ~/programming/network /bin /usr/src
[kermit@minty]~% dirs -v
0       ~
1       ~/programming
2       ~/programming/network
3       /bin
4       /usr/src
[kermit@minty]~%

As you can see, the directory stack was built from the list I entered plus the current working directory.

You might have noticed that every time you do a pushd (or popd), the next line is always the output of a dirs command. ~~I don't know of any way to silence this with bash~~, but with zsh, just add the following to your .zshrc:

setopt PUSHD_SILENT

To get the same effect in bash, you could do an alias for pushd and popd:

alias pushd='pushd > /dev/null'
alias popd='popd > /dev/null'

#If you did the +/- alias for pushd/popd as shown above, try

alias -- +='pushd > /dev/null'
alias -- -='popd > /dev/null'

Finally, if you use zsh, and you want to automatically store directory changes on the stack just by moving around with cd, put the following in your .zshrc:

setopt AUTO_PUSHD

With this option set, every cd command will act like a pushd command, storing your current directory on the stack, and then changing to the new directory. This will save you a lot of typing!

Conclusion

Unless you like the idea of typing more than necessary, you will want to use pushd, popd, and dirs to your advantage while on the command line, in order to save time, and wear and tear on your wrists/fingers. As always, consult your local man pages for particulars about the shell that you are using.

How to delete the 'Desktop' folder in Gnome...

2009-12-21T03:39:00.000-08:00

...and not have the contents of your home directory displayed on your desktop.

Maybe its just me, but I really don't like the way that a fresh Gnome install sets up a user's home directory with a bunch of empty directories, like 'Video', 'Documents', and the totally evil 'Desktop' folder. If you are like me, you want to decide what is in the home folder, which does not include all the extra directories they offer. A reasonable person would expect that the quick and easy solution would be to delete the unwanted directories, but not so fast my friend. All of the directories can be safely deleted, but one. If you remove the 'Desktop' folder, you will end up with all the contents of your home directory (not including hidden files) displayed on your desktop. Of course fixing your 'mistake' of deleting the Desktop folder is not as easy as doing a

mkdir ~/Desktop

No no, the wonderful people at Gnome must have thought that would be too easy. No, first you must search around on the internet and find a post like this one. Then you have to fire up your editor and do some editing, as well as replacing the folder 'Desktop.' Then all will be well. Except for the fact that your home directory still has a folder in it that YOU DON'T WANT!!!1!

Anyway, the solution is pretty simple. You still have to have some sort of directory to point Nautilus to, but nobody says it can't be hidden. Here is what you do:

Create a hidden directory like so:

mkdir ~/.desktop

Then open the file ~/.config/user-dirs.dirs with your favourite editor, eg:

vi ~/.config/user-dirs.dirs

In there you will see something like the following:

XDG_DESKTOP_DIR="$HOME/"
XDG_DOWNLOAD_DIR="$HOME/"
XDG_TEMPLATES_DIR="$HOME/"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/"
XDG_MUSIC_DIR="$HOME/"
XDG_PICTURES_DIR="$HOME/"
XDG_VIDEOS_DIR="$HOME/"

The line in red (above) is the one you want to change:

XDG_DESKTOP_DIR="$HOME/.desktop"

After this, you can kill nautilus (it should restart for you), or reboot your machine if you like, and your problem will be solved. You will not have the ugly mess of unwanted directories in your home folder, nor will your home folder be displayed on your desktop any longer.

ps headers and grep

2009-12-18T19:25:00.000-08:00

GNU ps(1) has a plethora of options. One of the more useful features of ps is the header label which is printed at the top of the ps output, such as in the following snippet:

Listing 1.1


char $ ps
  PID TTY                TIME CMD
15705 pts/1    00:00:00 bash
16345 pts/1    00:00:00 ps

As you can see, each column has a label on the top. In this example (Listing 1.1), the columns are labelled PID, TTY, TIME and CMD. This is the most basic invocation of the ps command, and the output is minimal. If you start adding options, such as doing ps aux, (where you will get you a listing of all the processes on the system using BSD style syntax) you will get quite a bit more text to sift through. But what if you are only after a certain term, such as tty, for example in the ps aux listing? To start with, you could pipe the output of ps into grep(1), in order to list only the things you are looking for:

Listing 1.2


char $ ps aux | grep tty
root      1588  0.0  0.0   1852   444 tty4     Ss+  Dec17   0:00 /sbin/mingetty tty4
root      1592  0.0  0.0   1852   440 tty6     Ss+  Dec17   0:00 /sbin/mingetty tty6
root      1634  2.2  2.7  46812 28332 tty1     Ss+  Dec17  42:09 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-6n8EnG/database -nolisten tcp vt1
root     12845  0.0  0.0   1852   444 tty3     Ss+  Dec17   0:00 /sbin/mingetty tty3
root     12898  0.0  0.0   1852   452 tty5     Ss+  Dec17   0:00 /sbin/mingetty tty5
root     14863  0.0  0.0   1852   452 tty2     Ss+  06:57   0:00 /sbin/mingetty tty2
kermit   16382  0.0  0.0   4192   780 pts/1    S+   21:42   0:00 grep tty

This works, but there are a couple of things I don't like about it. First of all, there are some instances of tty that I don't want. Most notable is the last line, which lists the instance of grep looking for 'tty'. We can get rid of this by doing a grep -v, which basically says 'don't match this,' where this is the term you supply.

Listing 1.3


char $ ps aux | grep tty | grep -v grep | grep -v tty1
root      1588   0.0  0.0   1852   444 tty4     Ss+  Dec17   0:00 /sbin/mingetty tty4
root      1592   0.0  0.0   1852   440 tty6     Ss+  Dec17   0:00 /sbin/mingetty tty6
root     12845  0.0  0.0   1852   444 tty3     Ss+  Dec17   0:00 /sbin/mingetty tty3
root     12898  0.0  0.0   1852   452 tty5     Ss+  Dec17   0:00 /sbin/mingetty tty5
root     14863  0.0  0.0   1852   452 tty2     Ss+  06:57   0:00 /sbin/mingetty tty2

This looks a lot better. Notice that I actually eliminated two entries with grep -v:

Listing 1.4
char $ ps aux | grep tty | grep -v grep | grep -v tty1

First, I got rid of the line listing grep (listing 1.4a below) as well as the long line with tty1 (listing 1.4b below).

Listing 1.4a


kermit   16382  0.0  0.0   4192   780 pts/1    S+   21:42   0:00 grep tty

Listing 1.4B


root      1634  2.2  2.7  46812 28332 tty1     Ss+  Dec17  42:09 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-6n8EnG/database -nolisten tcp vt1

In the interest of less typing, a way to shorten this string of commands would be to use the egrep(1) program, instead of grep. egrep allows for extended regular expression usage, and can be invoked either by egrep or grep -E.

Listing 1.5


char $ ps aux | grep tty | egrep -v 'grep|tty1'
root      1588   0.0  0.0   1852   444 tty4     Ss+  Dec17   0:00 /sbin/mingetty tty4
root      1592   0.0  0.0   1852   440 tty6     Ss+  Dec17   0:00 /sbin/mingetty tty6
root     12845  0.0  0.0   1852   444 tty3     Ss+  Dec17   0:00 /sbin/mingetty tty3
root     12898  0.0  0.0   1852   452 tty5     Ss+  Dec17   0:00 /sbin/mingetty tty5
root     14863  0.0  0.0   1852   452 tty2     Ss+  06:57   0:00 /sbin/mingetty tty2

As you can see, the command is shorter, but the output is still the same, and looks nice. There is one other problem though; there are eleven columns, but no label to indicate the kind of information being displayed. The label is printed with ps aux, but the grep output doesn't print that, because I didn't ask it to do that. I need to ask grep to display all the lines with tty and the header also. Once again I will use egrep to get what I am after:

Listing 1.6


char $ ps aux | egrep 'PID|tty' | egrep -v 'grep|tty1'
USER       PID %CPU %MEM    VSZ    RSS TTY      STAT START   TIME COMMAND
root      1588   0.0  0.0   1852   444 tty4     Ss+  Dec17   0:00 /sbin/mingetty tty4
root      1592   0.0  0.0   1852   440 tty6     Ss+  Dec17   0:00 /sbin/mingetty tty6
root     12845  0.0  0.0   1852   444 tty3     Ss+  Dec17   0:00 /sbin/mingetty tty3
root     12898  0.0  0.0   1852   452 tty5     Ss+  Dec17   0:00 /sbin/mingetty tty5
root     14863  0.0  0.0   1852   452 tty2     Ss+  06:57   0:00 /sbin/mingetty tty2

I told egrep to look for both 'PID' ('PID' is found in the header label, so grep finds it and prints the entire line) and 'tty,' but not to print any line with 'tty1' or 'grep' in it.

Final thoughts:

By chaining a couple of commands together with pipes, you can produce some pretty informative, and easy to read output. I would encourage you to read through your local man pages for ps and grep, to get a better handle on what options are available to you on your system.

The idea of using egrep to grab the ps header is not mine. I came across it in Æleen Frisch's book Essential System Administration, Second edition, pg 261. This edition of her book is now out of print, however the third edition is still available. I haven't read it (yet), but it is on my short list of books to buy. Ironically, I picked up my copy of the second edition in a clearance bin at a local store a number of years ago. I let it sit on my shelf for a long time after that. Then one day I decided to start reading it, and could not put it down. I still refer to it fairly regularly. It is a very good book, and I would recommend it to anyone who wishes to become better at doing sys-admin type work.

Find gotcha

2009-08-04T19:02:00.000-07:00

Not too sure if I can call this a bonafide 'gotcha,' but it is something to keep in mind.

It is a good idea to occasionally check your Unix system for orphaned files. Normally you do so by using find with the -nouser and -nogroup filters. You could do two separate searches, one for -nouser, and then one for -nogroup, but typically the two are combined in one find command. Now here is the gotcha:

find / -nouser -nogroup -print

If you search find "-nouser -nogroup" on Google you likely find some examples like the one above. The problem with it is that there is an implied and when two or more filters are used as in the example. It is the same as doing the following (explicitly):

find / -nouser -a -nogroup -print
or:
find / -nouser -and -nogroup -print

The examples above will only 'find' files that belong to 'nouser' and 'nogroup.' If a file matches -nouser, but not -nogroup, find will not display it. If a file exists that matches -nogroup, but not -nouser, it will not display. Find will only return results that meet both criteria. In order to find all orphaned files, you want to do an or:

find / -nouser -o -nogroup -print

Now go have some fun tracking down those orphaned files!

Getting rid of troublesome files with GNU find.

2009-08-03T17:48:00.000-07:00

Ok, so this isn't that much of a problem these days for those who are running a GUI, but what about when X isn't available? Consider the following:


kermit@fastbox ~/tmp/work2 $ ls -l
total 4
-rw-r--r-- 1 kermit kermit 37 2009-08-03 21:04 -pesky

I got that file by doing:


kermit@fastbox ~/tmp/work2 $ echo "Haha, sucker"\! "Try and get rid of me"\! > -pesky

Now try and issue the rm command on the file -pesky and you will find that it doesn't work so well. What can you do? Well, you can do what Bash tells you, and do:


kermit@fastbox ~/tmp/work2 $ rm -f ./-pesky

Or if you read the man page for rm, you would know that you can also do:


kermit@fastbox ~/tmp/work2 $ rm -f  -- -pesky  #The '--' tells the shell there are no more options following.

But there is another interesting way to do this operation, and it will work with other kinds of problematic, persistent files as well. We will use find to nuke the file. First, you need to find the inode number of the file, by using ls with the -i flag:


kermit@fastbox ~/tmp/work2 $ ls -li
total 4
8339920 -rw-r--r-- 1 kermit kermit 37 2009-08-03 20:57 -pesky

In this case, the inode number is 8339920. Now we can tell find to find the file with that number. Once it finds it, we can -exec /bin/rm -f and remove it:


kermit@fastbox ~/tmp/work2 $ find . -inum 8339920 -exec /bin/rm -f {} \;
kermit@fastbox ~/tmp/work2 $ ls -l
total 0

OpenSolaris 2008.11 - What is right, and what needs work

2009-02-09T09:18:00.000-08:00

A friend of mine was trying to compile a simple C program on his university shell account. It turns out that the server hosting his shell account runs some version of Solaris. Not being experienced with anything Sun, I was not as helpful as I would like to have been with his questions about invoking the compiler. Since I had often thought that I would like to give OpenSolaris a whirl, now seemed like a good time to try. This is a short account of my experience doing just that, triple booting Linux, FreeBSD, and OpenSolaris.

First of all, to boot OpenSolaris after installation, it is not just a matter of editing your grub.conf with an entry for OpenSolaris. The version of grub supplied with OpenSolaris is special, and needs to be installed in order to boot into that OS. This works ok, and you can either add your other entries to it, or you can do like I did and leave the original grub on /dev/hda, and then use an entry like this to get to either the FreeBSD bootloader or the OpenSolaris grub on /dev/hdb:


# For booting GNU/Linux
title  GNU/Linux 2.6.27-gentoo-r8
root (hd0,0)
kernel /boot/kernel-2.6.27-gentoo-r8 root=/dev/hda3 \
video=uvesafb:1280x1024-24,mtrr:3,ywrap \

#For booting FreeBSD
title FreeBSD
root (hd1,0)
savedefault
makeactive
chainloader +1

#For booting OpenSolaris
title OpenSolaris
root (hd1,1)
savedefault
makeactive
chainloader +1

The installation went very well. I popped in the livecd, and once the desktop came up, clicked on the icon there to install the OS. It made me fill in some info, like username/password stuff, as well as timezone etc., and partitions. Then it did the install. After that, all I had to do was reboot.

The boot into the full install was impressive. The screen resolution just worked, although nvidia twinview was not working immediately. All that was needed for that was to open a shell and enter 'pfexec nvidia-config' and then use the sweet utility to change the settings. You can read more about that here.

There were a few issues with drivers. I run an old Asus A8V-Deluxe motherboard, which is well supported under Linux and FreeBSD, but apparently not as well with OpenSolaris.

First off, it did not automatically do something intelligent with the Marvell 88E8001 Ethernet Controller. That was not too much trouble though, as I was able to boot back into Linux, download a driver, and then boot back into Solaris and install it. It worked well then, and the network automagically worked too.

The second problem was with the Sata Raid controller - no driver for that either. Not a problem for me, as I still am running a pair of ATA disks; for those of you with Sata, this could be trouble though.

The final problems were sound-card related. The Creative Sound Blaster X-Fi Extreme did not surprise me - it is hardly supported under Linux. But my old C-Media card was not picked up either. Oh well - Windows 7 had some trouble with that one too.

Over all, my impression of the install was favourable. I think that a lot of work has gone into the installer and sysconfig utilities, to make the experience a pleasant one, and it shows. Kudos to the people who are working on that end of OpenSolaris. I am also fairly impressed with the package management system which has a nice graphical user interface. Nice and easy to use, and from my experience, takes care of all the dependencies. It is on par with modern Linux distributions, if nothing else.

Now for the parts that I didn't like so much..

The first point is a minor one; though I was impressed with the initial boot, this had to do more with the fact that things worked, and not so much to do with the presentation. What I mean is that upon booting to the grub menu, the user is given two choices, either a regular boot (which happens to be a graphical frame-buffer deal with a 'sort of' progress bar. Basically it just keeps moving so you get the idea that something is going on, I guess.) or a text boot from the console. I selected this (text-boot) once, just to see how it looked and, as a Gentoo user, I can say that I was totally disappointed. There was hardly any information there at all. So if you are into a descriptive (and possibly interactive) boot process, forget about it with OpenSolaris.

The other thing I did not like was the fact that the default desktop is Gnome. Linus doesn't like Gnome, [1] and neither do I. And here is the kicker, KDE is not really offered. Sure, you can get an old version (i.e., 3.4x), or you can go for the super new 4.2x stuff, but no (easy) option for getting 3.5.9 on there. In my mind, this is a huge mistake. I have never really been able to get into Gnome, because it seems so hard to customise. All this said, I gather that it is not easy to get the KDE 3.x stuff running on OpenSolaris, and that the 4.x series promises to be good when it is ready. Until then, I guess I will stick with my Linux, FreeBSD and KDE.

[1]. Although he has been using it lately, and even developed a patch for it at some point, which the developers rejected.
Yes, you read that right; they rejected it. !!?? Hey guys, Linus sent you a patch! Put it in!

Building C and C++ Programs

2009-02-08T20:18:00.000-08:00

For a beginning programmer, sometimes the biggest problem is just getting a program to compile, as opposed to actually writing the program itself. That is why it is often helpful to do a little 'Hello, world!' program, just to get a feel for the system, how the compiler is invoked, and so on. So in this post, the reader will learn how to compile a 'Hello, world!' program for three different systems, in two different languages. The systems will be Linux, FreeBSD, and OpenSolaris. The first two will be similar in that they both (normally) employ gcc (GNU Compiler Collection, but formerly GNU C Compiler) as the standard system compiler. OpenSolaris is more interesting, as it makes the Sun C and C++ compilers available, as well as gcc. As for the languages, if you haven't already guessed, they will be C and C++. So let's begin with a C program, hello.c:

#include <stdio.h>

int main(void)
{
printf("Hello, world!\n");
return 0;
}

A simple program, one that lets the programmer concentrate on getting the compiler working, without having to worry about fixing source errors. Now then, the first thing to know is that on many (if not all) Unix like systems, the C compiler can generally be invoked with the command 'cc'. This may be the actual C compiler, named 'cc,' or the command may be a symlink to another compiler, such as gcc. In the latter case, the symlink is added for the sake of not breaking things. cc was the standard command for invoking the C compiler, and to take it away would, if nothing else, break tradition, not to mention some Makefiles as well. You can determine some basic information about where your C compiler resides (and if it is even installed!) by issuing the following command from the shell:

which cc

In the case of my OpenSolaris machine, this produces the following:

/usr/bin/cc

If I do an ls -l on /usr/bin/cc, I see that it is really just a symlink to another location on disk:

ls -l /usr/bin/cc
lrwxrwxrwx 1 root root 33 2009-02-08 22:52 /usr/bin/cc -> ../../opt/SunStudioExpress/bin/cc

All very interesting stuff. You could also do something like this:

cc -V

Which produces:

cc: Sun Ceres C 5.10 SunOS_i386 2008/10/22
usage: cc [ options] files.  Use 'cc -flags' for details

So in this case, at least, we know that when we use the command 'cc', we are invoking the Sun C compiler. So why don't we do that then - copy the program hello.c (above) into your favourite text editor, and save it as hello.c -- then, from the directory that you save the hello.c file, invoke the C compiler with the following command:

cc -o hello hello.c

and hit Enter. You should get your shell prompt back almost immediately. What you have done with the above command is to run the C compiler (cc), with the compiled output being called 'hello' (-o hello -- -o stands for output name. If you don't do the -o option, the program will still compile, with the executable being named a.out -- this is also a tradition in Unix like systems. If you run a.out, it will print 'Hello, world!' to the standard output. a.out stands for 'assembler output,' which is a fallback to older systems and procedures.) and the input source file to the compiler being hello.c

As you can see, there is not much to it. If you do an ls -l in the directory where you ran the compiler from, you should see the executable file, 'hello' You can run it by typing in:

./hello

The ./ part of ./hello means 'Run the program 'hello' which is found in this directory.
With OpenSolaris, you have the option to install another compiler as well, namely, gcc. You can issue the same commands to find out where gcc exists and which version you are using:

which gcc
/usr/bin/gcc

ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 14 2009-02-08 23:20 /usr/bin/gcc -> ../sfw/bin/gcc

Keep in mind that determining the version of gcc is slightly different than the way you do it for cc:

gcc -v

Note that it is a small v as opposed to a large V for cc. You can read more about the compiler command switches by doing man cc or man gcc to access the manual page for each compiler.

If you decide to use gcc, you ought to use two flags every time you compile. They are the -Wall (Warnings All) and the -Wextra (Warnings extra) flags. By using them, the compiler will give you lots of extra info with any problems your source code might have. Their use is indispensable, in my opinion. Use them like this:

gcc -Wall -Wextra -o hello hello.c

And here is the added bonus - if you can compile like this on OpenSolaris (Sun), then you can do it under Linux or FreeBSD, which come with gcc as the standard compiler.

Now then, on to compiling C++ programs. First, we need a suitable 'Hello, world!' program:

#include <iostream>

using namespace std;

int main()
{
cout << "Hello, world!" << endl;
return 0;
}

Now the interesting thing about C++ programs is that there are several standard ways of naming with a suffix. With C, a file is foo.c, such as hello.c -- but with C++ it might be hello.C (note the capital C), or hello.cc, or hello.cpp, or hello.cxx For our purposes, we will stick to hello.cc So how do we compile it? Well, if you want to go the traditional route, you would invoke the C++ compiler like this:

CC -o hello hello.cc

Note the capital CC; pretty imaginative, huh? That is simple, and easy to remember though. If you want to use the GNU C++ compiler, you would do:

g++ -o hello hello.cc

Both of these methods would produce an executable named 'hello,' which could then be invoked as with './hello' at the command prompt. If you use g++, once again, you can (and should) use the -Wall -Wextra flags. Also, you can use g++ in the same fashion on any other system which has the GNU Compiler Collection available, such as Linux, or FreeBSD.

Getting a simple directory listing in Linux

2009-02-01T10:39:00.000-08:00

There are often many ways to do the same things under Linux; getting a listing of a given directory falls under that category. The easiest way is to issue the command, 'ls -l', in the shell. Alternatively, if you don't mind a bit of work, you could write your own program.

Lately, I have been reading Steve D. Pate's UNIX Filesystems -- Evolution, Design, and Implementation. I am at the section in the book (pp.21-22) where the author implements a simple version of the Unix style ls command. The book itself was published in 2003 and, as things stand in 2009, the code example he lists will not even compile. Here is the code:

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/dirent.h>
#include <sys/unistd.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <pwd.h>
#include <grp.h>

#define BUFSZ 1024

main()
{
    struct dirent *dir;
    struct stat st;
    struct passwd *pw;
    struct group *grp;
    char buf[BUFSZ], *bp, *ftime;
    int dfd, fd, nread;

    dfd = open(".", O_RDONLY);
    bzero(buf, BUFSZ);
    while (nread = getdents(dfd, (struct dirent *) &buf, BUFSZ) != 0) {
        bp = buf;
        dir = (struct dirent *) buf;
        do {
            if (dir->d_reclen != 0) {
                stat(dir->d_name, &st);
                ftime = ctime(&st.st_mtime);
                ftime[16] = '\0';
                ftime += 4;
                pw = getpwuid(st.st_uid);
                grp = getgrgid(st.st_gid);
                perms(st.st_mode);
                printf("%3d %-8s %-7s %9d %s %s\n",
                       st.st_nlink, pw->pw_name, grp->gr_name,
                       st.st_size, ftime, dir->d_name);
            }
            bp = bp + dir->d_reclen;
            dir = (struct dirent *) (bp);
        } while (dir->d_ino != 0);
        bzero(buf, BUFSZ);
    }
}

Here is what I get when I try to compile it on my machine:

kermit@fastbox ~/cprogs/fs $ gcc -Wall -o pate_ls pate_ls.c
pate_ls.c:3:24: error: sys/dirent.h: No such file or directory
pate_ls.c:14: warning: return type defaults to ‘int’
pate_ls.c: In function ‘main’:
pate_ls.c:23: warning: implicit declaration of function ‘bzero’
pate_ls.c:23: warning: incompatible implicit declaration of built-in function ‘bzero’
pate_ls.c:24: warning: implicit declaration of function ‘getdents’
pate_ls.c:24: warning: suggest parentheses around assignment used as truth value
pate_ls.c:28: error: dereferencing pointer to incomplete type
pate_ls.c:29: error: dereferencing pointer to incomplete type
pate_ls.c:30: warning: implicit declaration of function ‘ctime’
pate_ls.c:30: warning: assignment makes pointer from integer without a cast
pate_ls.c:35: warning: implicit declaration of function ‘perms’
pate_ls.c:36: warning: implicit declaration of function ‘printf’
pate_ls.c:36: warning: incompatible implicit declaration of built-in function ‘printf’
pate_ls.c:38: error: dereferencing pointer to incomplete type
pate_ls.c:38: warning: format ‘%3d’ expects type ‘int’, but argument 2 has type ‘__nlink_t’
pate_ls.c:38: warning: format ‘%9d’ expects type ‘int’, but argument 5 has type ‘__off_t’
pate_ls.c:40: error: dereferencing pointer to incomplete type
pate_ls.c:42: error: dereferencing pointer to incomplete type
pate_ls.c:20: warning: unused variable ‘fd’
pate_ls.c:45: warning: control reaches end of non-void function
kermit@fastbox ~/cprogs/fs/tmp $

That's a lot to look at! What we need to do is make some changes, so that the code will compile cleanly. Before dealing with the errors and warnings though, we will first look at the only 'major' change to the code, which will have a bonus side effect of eliminating some of the other problems. What we are going to do, is get rid of the call to getdents. If you look at your man page for getdents, you will notice the following:

"This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface."

I am not sure if getdents was ever able to be used under Linux, such as is demonstrated above, but it certainly is not now. Instead, if we want to read a directory, we can use the readdir system call. Furthermore, instead of using the open system call on a directory, we can use the opendir system call that is provided under Linux. By using readdir, we can get rid of a few variables, notably the buf array, which also eliminates the need for the call to bzero. (Incidentally, if you read the man page for bzero, you will notice that it is being deprecated in favour of the memset function). Let's have a look at the original code again, with some comments annotating some of the problems with regards to building it under Linux:

#include <sys/types.h> 
#include <sys/stat.h> 
#include <sys/dirent.h>         /* Does not exist under some   
                                 * (all?) Linux distributions 
                                 */ 
#include <sys/unistd.h> 
#include <fcntl.h> 
#include <unistd.h> 
#include <errno.h> 
#include <pwd.h> 
#include <grp.h> 
 
#define BUFSZ 1024 
 
main() 
{                               /* Main returns an int */ 
    struct dirent *dir; 
    struct stat st; 
    struct passwd *pw; 
    struct group *grp; 
    char buf[BUFSZ], *bp, *ftime; 
    int dfd, fd, nread; 
 
    dfd = open(".", O_RDONLY); 
    bzero(buf, BUFSZ);          /* #include <strings.h> for bzero, 
                                 * but we don't need to use 
                                 * bzero (or memset) if we use 
                                 * readdir instead of getdents 
                                 */ 
    while (nread = getdents(dfd, (struct dirent *) &buf, BUFSZ) != 0) { 
        /* We can use readdir instead 
         * of getdents.  Example will 
         * follow later. 
         */ 
        bp = buf; 
        dir = (struct dirent *) buf; 
        do { 
            if (dir->d_reclen != 0) { 
                stat(dir->d_name, &st); 
                ftime = ctime(&st.st_mtime);    /* #include <time.h> 
                                                 * for ctime()  
                                                 */ 
                ftime[16] = '\0'; 
                ftime += 4; 
                pw = getpwuid(st.st_uid); 
                grp = getgrgid(st.st_gid); 
                perms(st.st_mode); 
                printf("%3d %-8s %-7s %9d %s %s\n", 
                       /* #include <stdio.h> 
                        * for printf()  
                        */ 
                       st.st_nlink, pw->pw_name, grp->gr_name, 
                       st.st_size, ftime, dir->d_name); 
            } 
            bp = bp + dir->d_reclen; 
            dir = (struct dirent *) (bp); 
        } while (dir->d_ino != 0); 
        bzero(buf, BUFSZ); 
    } 
    /* Should return something, as main returns an int */ 
}

And finally, have a look at what the new program, with the changes, looks like:

#include <sys/types.h>          /* opendir, stat, closedir */
#include <dirent.h>             /* opendir, readdir, closedir */
#include <errno.h>              /* perror */
#include <stdlib.h>             /* exit */
#include <sys/stat.h>           /* stat */
#include <unistd.h>             /* stat */
#include <time.h>               /* ctime */
#include <pwd.h>                /* getpwuid */
#include <grp.h>                /* getgrgid */
#include <stdio.h>              /* printf */

int main(void)
{
    DIR *dp;
    struct dirent *dirp;
    struct stat st;
    struct passwd *pw;
    struct group *grp;
    char *ftime;

    if ((dp = opendir(".")) == NULL) {
        printf("Cannot open this directory\n");
        perror("opendir");
        exit(EXIT_FAILURE);
    }

    while ((dirp = readdir(dp)) != NULL) {
        if (dirp->d_reclen != 0) {
            stat(dirp->d_name, &st);
            ftime = ctime(&st.st_mtime);
            ftime[16] = '\0';
            ftime += 4;
            pw = getpwuid(st.st_uid);
            grp = getgrgid(st.st_gid);
            printf("%3zu %-8s %-7s %9zu %s %s\n",
                   st.st_nlink, pw->pw_name, grp->gr_name,
                   st.st_size, ftime, dirp->d_name);
        }
    }

    closedir(dp);
    return 0;
}

It compiles cleanly on my system (kernel 2.6.27, gcc 4.1.2). Note that this implementation is very 'bare bones.' It lists everything in the directory where it is executed (provided the directory permission settings allows it to do so). This includes 'hidden' dot files (.somefile), as well as the current directory, dot (.), and the parent directory, dot-dot (..). Now that you have a working version of the program, I would encourage you to experiment with it, and do the other exercises such as making it accept user input so as to be able to perform long and short listings (and even the -a option to show hidden files) etc. Finally, I have included a diff of the two files, in order to give an idea of what has been changed:

1,9c1,10
< #include <sys/types.h> 
< #include <sys/stat.h> 
< #include <sys/dirent.h> 
< #include <sys/unistd.h> 
< #include <fcntl.h> 
< #include <unistd.h> 
< #include <errno.h> 
< #include <pwd.h> 
< #include <grp.h> 
--- 
> #include <sys/types.h>         /* opendir, stat, closedir */
> #include <dirent.h>            /* opendir, readdir, closedir */
> #include <errno.h>             /* perror */
> #include <stdlib.h>            /* exit */
> #include <sys/stat.h>          /* stat */
> #include <unistd.h>            /* stat */
> #include <time.h>              /* ctime */
> #include <pwd.h>               /* getpwuid */
> #include <grp.h>               /* getgrgid */
> #include <stdio.h>             /* printf */
---
< #define BUFSZ 1024
---
13c14
< main()
---
> int main(void)
15c16,17
<     struct dirent *dir;
---
>     DIR *dp;
>     struct dirent *dirp;
19,20c21
<     char buf[BUFSZ], *bp, *ftime;
<     int dfd, fd, nread;
---
>     char *ftime;
22,43c23,26
<     dfd = open(".", O_RDONLY);
<     bzero(buf, BUFSZ);
<     while (nread = getdents(dfd, (struct dirent *) &buf, BUFSZ) != 0) {
<         bp = buf;
<         dir = (struct dirent *) buf;
<         do {
<             if (dir->d_reclen != 0) {
<                 stat(dir->d_name, &st);
<                 ftime = ctime(&st.st_mtime);
<                 ftime[16] = '\0';
<                 ftime += 4;
<                 pw = getpwuid(st.st_uid);
<                 grp = getgrgid(st.st_gid);
<                 perms(st.st_mode);
<                 printf("%3d %-8s %-7s %9d %s %s\n",
<                        st.st_nlink, pw->pw_name, grp->gr_name,
<                        st.st_size, ftime, dir->d_name);
<             }
<             bp = bp + dir->d_reclen;
<             dir = (struct dirent *) (bp);
<         } while (dir->d_ino != 0);
<         bzero(buf, BUFSZ);
---
>     if ((dp = opendir(".")) == NULL) {
>         printf("Cannot open this directory\n");
>         perror("opendir");
>         exit(EXIT_FAILURE);
44a28,44
>
>     while ((dirp = readdir(dp)) != NULL) {
>         if (dirp->d_reclen != 0) {
>             stat(dirp->d_name, &st);
>             ftime = ctime(&st.st_mtime);
>             ftime[16] = '\0';
>             ftime += 4;
>             pw = getpwuid(st.st_uid);
>             grp = getgrgid(st.st_gid);
>             printf("%3zu %-8s %-7s %9zu %s %s\n",
>                    st.st_nlink, pw->pw_name, grp->gr_name,
>                    st.st_size, ftime, dirp->d_name);
>         }
>     }
>
>     closedir(dp);
>     return 0;