zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <zefram@fysh.org>
To: Clint Adams <clint@zsh.org>
Cc: zsh-workers@sunsite.dk, 131337-forwarded@bugs.debian.org
Subject: Re: problems with RANDOM in subshells
Date: Thu, 31 Jan 2002 03:46:51 +0000	[thread overview]
Message-ID: <20020131034651.GB7382@fysh.org> (raw)
In-Reply-To: <20020131032041.GA13560@dman.com>

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


  reply	other threads:[~2002-01-31  3:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-31  3:20 Clint Adams
2002-01-31  3:46 ` Zefram [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020131034651.GB7382@fysh.org \
    --to=zefram@fysh.org \
    --cc=131337-forwarded@bugs.debian.org \
    --cc=clint@zsh.org \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).