I would have expected that either (a) the value assigned to $mode would depend on @ARGV (or %ENV, or some other external input), or (b) there would be something inside the loop that could change the value of $mode, or else (c) each time you edit the script to change its behavior, rather than editing a variable assignment, you would just edit the loop condition -- e.g. do {...} while(0); vs. do {...} while(1);, or something to that effect. (Note that the former "do" block will execute exactly once, whereas the block in while(0){...} never executes.)

As it is, I tend to share muba's puzzlement.

(updated to fix spelling)

yep, that was the intended design. the scripts purpose is to randomly select a wallpaper and set it in gnome2. i can then add it to my startup scripts, and it'll change the wallpaper, either once at login, or continuously while i am logged in, depending upon what i've set $mode to.

i've modified it a bit more though, so maybe this makes more sense...

Read more... (2 kB)

Yes, that does make more sense. Just one word of caution though... Instead of this:

    # Interval to change at if we want $mode = "running"
    my $interval = $ARGV[0];

    # Change the mode if we have been passed an interval
    $mode = "running" if ($interval);
[download]

something like this would be more prudent:

my $interval = 0;
if ( @ARGV ) {
    ( $interval ) = ( $ARGV[0] =~ /(\d+)/ )
        or die "Usage: $0 [m]\n m: number of minutes between color cha
+nges\n";
}
$mode = "running" if ( $interval );
[download]

That makes sure that you don't try to do arithmetic on a non-numeric string, or sleep for a negative number of seconds.

(update -- minor nit-pick -- since you now have an "interval" variable that is either true or false, you don't really need a "mode" variable, do you?)