This is in response to a private message I received (since I can't send PMs until I have 10 posts...).

I've implemented this linear congruential generator in C to generate the correct sequence of integers (that is, what I'm expecting from this shell function):

Code:

#include <stdio.h>
#include <unistd.h>
#include <stdint.h>

uint32_t
myrand()
{
    static uint32_t rand_x = 1;

    rand_x = (rand_x * 1103515245 + 12345) % 4294967296;

    return rand_x;
}

int
main(int argc, char **argv)
{
    for (;;) {
        printf("%u\n", myrand());
        sleep(2);
    }   

    return 0;
}

And here is the printed sequence:
If I use "return" instead of "echo" and get the value in $? after calling rand(), my shell terminates with the following:
So it's generating the correct number. I guess the problem is that this number is 32 bits long and would exceed a signed long integer on my i686 system. Oops.

I changed my modulus, multiplier, and increment so the returned value doesn't exceed 2^31. So now this works:

Code:

#! /bin/sh

rand_x=1

rand()
{
    rand_x=$(((($rand_x * 65537) + 12345) % 2147483648))
    return $rand_x
}

while true; do
    rand
    printf '%i %i\n' $? $(($? % 3))
    sleep 2
done

For some reason "echo" still just resets $rand_x to its original value... I wish I knew why it did that. But I'll just use "return".

I'll test this script in a few different shells now to see if the signed long issue affects numbers before they're wrapped with modulo. If not, I think this problem is solved.

EDIT:
Harish: I know it's an infinite loop. I just interrupt it after a few iterations.
Ygor: Oh, I didn't realize command substitution used a subshell (I see it now in POSIX.1-2008) or that variables are set differently in a subshell. Yeah, that explains the weird behavior with "echo" then. Thanks!

EDIT 2:
I used these new values in three different shells so far (GNU Bash, dash, and BusyBox ash) and in C (modifying the above code). I generated 1000 pseudorandom numbers using all four test cases, and all four results were equal. I think the results are undefined if there is overflow in the intermediate arithmetic though. Oh well; I'll test more shells to be sure.

EDIT 3:
Well I've tested 8 shells (GNU Bash, dash, BusyBox ash, zsh, csh, tcsh, ksh, and mksh) across two PC architectures, haha. All give the same 1000 numbers (seeded at 1), so the arithmetic seems portable. Anyway, thanks again Ygor and Harish!