Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Introduction and Patch Approval Process
Home

[Freeciv-Dev] Re: Introduction and Patch Approval Process

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: David Weisgerber <tnt@xxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Introduction and Patch Approval Process
From: Kevin Brown <kevin@xxxxxxxxxxxxxx>
Date: Thu, 16 Aug 2001 10:42:32 -0700

David Weisgerber <tnt@xxxxxxxxx> wrote:

> Oh I didn't think about that but we can integrate such things one
> step after the other.  We don't have to disable sound if play isn't
> available because the only thing it would be some thousands of
> "command not found" outputs...  But I'll see what to do.

Just look at the exit value.  You're basically going to be doing
something like:

if (playsounds) {
    pid = fork();
    if (pid > 0) {
        /* child */
        execlp (playcmd, playcmd, soundfile);
        /* If we get here then the exec failed, probably because the play
           command doesn't exist */
        exit (PLAYNOTFOUND);
    } else {
        /* parent.  Normally we'd test for fork() failure, but this is just
           an example, not the real deal */
        wait(&status);
        if (WEXITSTATUS(status) == PLAYNOTFOUND) {
            /* Turn off sound play, and log it */
            freelog(LOG_ERROR, "Can't play sounds because I can't find the play 
command '%s'", playcmd);
            playsounds = 0;
        }
    }
}


And yeah, I agree that the refinements can happen after the basics are
in place.  This isn't the sort of thing that must be done completely
right the first time, as long as the basics are solid.


-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.


[Prev in Thread] Current Thread [Next in Thread]