Thomas Habets wrote:
> (if this email goes to a mailinglist then I'm not on it. Please CC
> any replies if that is the case)
> [...]
> So, added -R, --random.

I like the idea of providing a pseudo-randomizing, shuffling
capability.  I have actually wanted that myself on occasion.  Normally
to do this I usually use the nonstandard $RANDOM extension provided by
/bin/ksh and look-alikes such as /bin/bash to shuffle files this way:

  while read line; do echo $RANDOM "$line"; done < DATAFILE \
  | sort -n | sed 's/^[[:digit:]]*[[:space:]]//'

Often I would also like to have a way to repeat that ordering.
Therefore creating a random option begs for the addition of a way to
seed the generator with a value so that the same pseudo random order
can be generated again.

Also, you seed the PRNG with the system time in seconds.  I am not
educated with such matters but I feel certain this will come under
file later as being a poor RN seed.  I would hate to see a simple
feature like this which is not concerned about the strength of the
PRNG be added but then be the cause of a problem in a completely
different application which requires a strong PRNG.

> Note that I use rand() and srand(), if that matters on some OS.

I believe a full implementation will probably need to have autoconf
determine the proper pseudo-random number generator implementation.

Jim Meyering has previously posted guidelines for submissions to the
coreutils.  Attached are two previously statements posted to these
lists concerning this.  In particular I believe your submission is
large enough to warrent a copyright assignment to the FSF.  Do you
have one on file?

Bob
-----------------
Here are some guidelines for contributing code to the coreutils
package (previously known as the fileutils, textutils, and sh-utils).

Send patches. (send unified diffs, please -- i.e. diff -u format) If your
changes fix bugs, the bar is quite low in that I don't need much more
than to understand what the original problem was.  However, it helps
a lot if you can give me enough information to reproduce the problem.

On the other hand, if you're adding new features, please follow the
guidelines below:

  - convince me that this is a useful change/addition
      (if you're adding yet another option to ls, the above is pretty hard)

  - convince other people of the same thing
      One way to do that is to send mail to [EMAIL PROTECTED]
      (aka the gnu.utils.bug news group) including as much description
      and justification as you can.  Based on the feedback that generates,
      you may be able to convince me.

Once we agree the change is useful and get around to considering the
actual addition to the code, it helps if you do the following:

  - base your changes on the latest test release -- currently here:
      ftp://alpha.gnu.org/gnu/coreutils/; better still, you can base
      your changes on the latest code in CVS, here:
      http://savannah.gnu.org/cvs/?group=coreutils

  - follow the guidelines in the GNU Coding Standards (standards.info)
      which is distributed as part of the autoconf package.

  - include changes to the texinfo documentation, and be sure to update
      the --help output.

  - finally, if the change is `significant' you'll have to send signed
      copyright assignment papers to the FSF

And you'll have to be patient and expect delays on my part.
It is unusual that I spend more than a few hours per week
on the packages I maintain.
It's a two-step process.  First, you send some info to the FSF, then
we mail you the actual paperwork to sign.  Assignments have to be done
on physical paper to satisfy the requirements of copyright law.  When you
fill out the form, the answer to the "employer" question depends on
whether you intend to use any of the old code.

Please email the following information to [EMAIL PROTECTED], and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to