* problems with RANDOM in subshells @ 2002-01-31 3:20 Clint Adams 2002-01-31 3:46 ` Zefram 0 siblings, 1 reply; 6+ messages in thread From: Clint Adams @ 2002-01-31 3:20 UTC (permalink / raw) To: zsh-workers; +Cc: 131337-forwarded One can work around the problem described below by doing : $RANDOM ; (echo $RANDOM) | cat Should the random-seeding behavior be changed for subshells? ----- Forwarded message from Falk Hueffner <falk@debian.org> ----- For each subshell, $RANDOM gets initialized to the same value, which leads to the same sequence of random numbers. This makes e. g. playlist shuffling functions way boring, and is generally not what one would expect. falk@borkum:~% (echo $RANDOM) | cat 12042 falk@borkum:~% (echo $RANDOM) | cat 12042 falk@borkum:~% (echo $RANDOM) | cat 12042 Falk -- System Information Debian Release: 3.0 Architecture: alpha Kernel: Linux borkum 2.4.16 #1 Sat Dec 1 23:02:59 CET 2001 alpha Locale: LANG=C, LC_CTYPE=de_DE Versions of packages zsh depends on: ii libc6.1 2.2.4-7 GNU C Library: Shared libraries an ii libcap1 1:1.10-12 support for getting/setting POSIX. ii libncurses5 5.2.20020112a-2 Shared libraries for terminal hand ----- End forwarded message ----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problems with RANDOM in subshells 2002-01-31 3:20 problems with RANDOM in subshells Clint Adams @ 2002-01-31 3:46 ` Zefram 2002-01-31 4:03 ` Bart Schaefer 2002-01-31 11:07 ` Peter Stephenson 0 siblings, 2 replies; 6+ messages in thread From: Zefram @ 2002-01-31 3:46 UTC (permalink / raw) To: Clint Adams; +Cc: zsh-workers, 131337-forwarded Clint Adams wrote: >Should the random-seeding behavior be changed for subshells? No. We define $RANDOM to be a PRNG; zshparam(1) speaks of seeding it (by writing to $RANDOM). Opening a subshell should not interfere with the PRNG sequence, which one might be relying on to be reproducible. That is, we should maintain this useful behaviour: % RANDOM=1234; echo $RANDOM; echo $RANDOM 8718 31363 % RANDOM=1234; echo $RANDOM; (echo $RANDOM) 8718 31363 % RANDOM=1234; (echo $RANDOM; echo $RANDOM) 8718 31363 % (RANDOM=1234; echo $RANDOM; echo $RANDOM) 8718 31363 Where one requires unpredictability rather than reproducibility, it is well known (see Knoth vol. 2, et al) that one must take extra steps. For example, in an application that forks off subshells and needs a new random number in each subshell, one must at minimum step the PRNG between subshells. (Either each subshell uses the next random number generated by the main program, or each runs the PRNG itself, duplicating a random number that the main program generates and throws away.) To get wildly different random *sequences* in each subshell, rather than just a single random number, one can kink the PRNG sequence by doing "RANDOM=$RANDOM" between subshells. (In my interactive zsh setup, I step the PRNG with ": $RANDOM" in precmd. This largely solves the problem for interactive use of $RANDOM -- subshells started at different prompts get different (albeit overlapping) $RANDOM sequences.) For zsh-workers: It may be useful to add, separately from the PRNG, an entropy collection module. This would generate moderate-quality *unpredictable* numbers on demand; unlike the $RANDOM PRNG its output would be irreproducible. The shell is probably a good place to put an entropy collector; on systems like Linux that have /dev/random we can just use the kernel device, but on other systems the shell is still in a position to see a lot of unpredictable timing data, so we can make randomness reliably available to shell scripts on all Unices. (Does Perl have such a module yet?) -zefram ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problems with RANDOM in subshells 2002-01-31 3:46 ` Zefram @ 2002-01-31 4:03 ` Bart Schaefer 2002-01-31 4:06 ` Bart Schaefer 2002-01-31 11:07 ` Peter Stephenson 1 sibling, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2002-01-31 4:03 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Jan 31, 3:46am, Zefram wrote: } Subject: Re: problems with RANDOM in subshells } } The shell is probably a good place to put an entropy collector; on systems } like Linux that have /dev/random we can just use the kernel device, } but on other systems the shell is still in a position to see a lot of } unpredictable timing data, so we can make randomness reliably available } to shell scripts on all Unices. (Does Perl have such a module yet?) According to search.cpan.org: Statistics-MaxEntropy-0.9 by Hugo WL ter Doest Released 26th November 1998 -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problems with RANDOM in subshells 2002-01-31 4:03 ` Bart Schaefer @ 2002-01-31 4:06 ` Bart Schaefer 2002-01-31 11:34 ` Peter Stephenson 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2002-01-31 4:06 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Jan 31, 4:03am, Bart Schaefer wrote: } } According to search.cpan.org: } } Statistics-MaxEntropy-0.9 by Hugo WL ter Doest Released 26th November 1998 Sorry, that turns out not to be what I at first thought. Crypt::Random looks like a better choice, or Math-TrulyRandom-1.0. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problems with RANDOM in subshells 2002-01-31 4:06 ` Bart Schaefer @ 2002-01-31 11:34 ` Peter Stephenson 0 siblings, 0 replies; 6+ messages in thread From: Peter Stephenson @ 2002-01-31 11:34 UTC (permalink / raw) To: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 1582 bytes --] Guess what? Forgot to change the `To:' line again. "Bart Schaefer" wrote: > On Jan 31, 4:03am, Bart Schaefer wrote: > } > } According to search.cpan.org: > } > } Statistics-MaxEntropy-0.9 by Hugo WL ter Doest Released 26th November 1998 > > Sorry, that turns out not to be what I at first thought. > > Crypt::Random looks like a better choice, or Math-TrulyRandom-1.0. Crypt::Random simply uses /dev/random. However, Math-TrulyRandom is based on a short C program which has a nice, simple copyright, so we could simply include it. It may need some work porting to other UNIX variants. There's no encryption involved, so I don't think the warning about export controls is applicable. On the other hand, we don't have a built-in MD5 or DES to run on it. The nearest we have is the hashing function. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** [-- Attachment #2: RNG C code --] [-- Type: text/plain, Size: 2905 bytes --] /* * Physically random numbers (very nearly uniform) * D. P. Mitchell * Modified by Matt Blaze 2/95 */ /* * The authors of this software are Don Mitchell and Matt Blaze. * Copyright (c) 1995 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software may be subject to United States export controls. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. */ /* * WARNING: depending on the particular platform, truerand() output may * be biased or correlated. In general, you can expect about 16 bits of * "pseudo-entropy" out of each 32 bit word returned by truerand(), * but it may not be uniformly diffused. You should therefore run * the output through some post-whitening function (like MD5 or DES or * whatever) before using it to generate key material. (RSAREF's * random package does this for you when you feed truerand() bits to the * seed input function.) * * Test these assumptions on your own platform before fielding a system * based on this software or these techniques. * * This software seems to work well (at 16 bits per truerand() call) on * a Sun Sparc-20 under SunOS 4.1.3 and on a P100 under BSDI 2.0. You're * on your own elsewhere. */ #include <signal.h> #include <setjmp.h> #include <sys/time.h> #include <math.h> #include <stdio.h> #include "truerand.h" static jmp_buf env; static unsigned count; static unsigned ocount; static unsigned buffer; static int tick() { struct itimerval it, oit; timerclear(&it.it_interval); it.it_value.tv_sec = 0; it.it_value.tv_usec = 16665; if (setitimer(ITIMER_REAL, &it, &oit) < 0) perror("tick"); } static void interrupt() { if (count) longjmp(env, 1); (void) signal(SIGALRM, interrupt); tick(); } static unsigned long roulette() { if (setjmp(env)) { count ^= (count>>3) ^ (count>>6) ^ ocount; count &= 0x7; ocount=count; buffer = (buffer<<3) ^ count; return buffer; } (void) signal(SIGALRM, interrupt); count = 0; tick(); for (;;) count++; /* about 1 MHz on VAX 11/780 */ } unsigned long truerand() { count=0; (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); (void) roulette(); return roulette(); } int n_truerand(n) int n; { int slop, v; slop = 0x7FFFFFFF % n; do { v = truerand() >> 1; } while (v <= slop); return v % n; } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: problems with RANDOM in subshells 2002-01-31 3:46 ` Zefram 2002-01-31 4:03 ` Bart Schaefer @ 2002-01-31 11:07 ` Peter Stephenson 1 sibling, 0 replies; 6+ messages in thread From: Peter Stephenson @ 2002-01-31 11:07 UTC (permalink / raw) To: Zsh hackers list Zefram wrote: > Clint Adams wrote: > >Should the random-seeding behavior be changed for subshells? > > No. We define $RANDOM to be a PRNG; zshparam(1) speaks of seeding it > (by writing to $RANDOM). Opening a subshell should not interfere with > the PRNG sequence, which one might be relying on to be reproducible. bash has the zsh behaviour, but ksh 88 handles subshells specially. POSIX/SUS doesn't defined RANDOM, but we probably ought to get this specified for David Korn's enhanced shell proposal, given that all three shells under discussion already have RANDOM. It does seem to me that it's unnecessarily hard for a user to take avoiding action in a subshell. At least providing the PID of the subshell process as separate parameter might give them the start, e.g. make $ZSH_REALPID map directly to getpid() --- obviously not with a very high degree of randomness, but I don't think that was a problem in this case. (The advantage over providing a real `random' number is that it takes a minute to write instead of a day.) -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-01-31 11:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-31 3:20 problems with RANDOM in subshells Clint Adams 2002-01-31 3:46 ` Zefram 2002-01-31 4:03 ` Bart Schaefer 2002-01-31 4:06 ` Bart Schaefer 2002-01-31 11:34 ` Peter Stephenson 2002-01-31 11:07 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).