tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: randomness (crypto?) code example wanted please?



    Date:        Tue, 27 Jun 2017 16:23:25 -0700
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1dPzpN-0036rzC@more.local>


  | For what it is worth I've been using the likes of:
  | 
  | 	if [ ${RANDOM:-0} -ne ${RANDOM:-0} ] ; then
  | 		: is some kind of ksh variant or clone
  | 	fi
  | 
  | since I first encountered ksh, probably in the mid 1980s

I'd be interested in knowing what kinds of things that you do differently
when that is the distinction you're using - that would lump all ksh
variants, bash, yash, and even zsh (maybe more) into the "ksh line"
leaving mostly dash (and the NetBSD sh, and other ash derivatives), and
bosh (basically an older Sys V shell, modernised), and maybe what few
commercial distributions are still around - as the other
group (where bosh (and usually the commercial shells) and ash shells
are really nothing alike at all.)

For just testing for a something claimimg to be a ksh seeing if KSH_VERSION
is set seems like a better idea, they all implement that I believe (if you
need to know which one, you can look at its value).

But claiming that bash, yash and especially, zsh are "ksh variants or clones"
is going a little far, unless you just want a shell which has the useful stuff
first implemented in ksh, which apart from RANDOM, mostly means all shells
these days (a few ancient commercial ones excepted.)

  | (and many of those without $RANDOM have few other
  | features that can reliably class them as non-ksh-like).

In that case, why would you care?   That is, unless it is $RANDOM
itself that you want - for that the check above is ideal.

  | Of course I'm not at all opposed to adding $RANDOM to any shell, or
  | indeed to POSIX.

POSIX evidently decided that RANDOM wasn't really needed for interactive
users, and so left it out (or that's what the rationale says), even though
the emphasis everywhere else is on script features, with interactive use
coming off distinctly second best - which is not all that surprising, as
interactive users can adapt to differences in the environment, we might not
like it much, but we can learn the differences, and adapt.  scripts don't
have that ability - they simply exist...

  | I just wanted to point out that this remains reliable to this day so
  | that I can drop my dot files on any system and expect them to work no
  | matter what login shell I've been given.

For what I need in my dot files, I find that they mostly work on any
(non c) shell, with essentially no changes - the only real issue is that
some shells (still) restrict function names to the same syntax as var
names, which is both unnecessary, and dumb.

  | Again for what it's worth I think though that a NetBSD /bin/sh with
  | $RANDOM will probably pass muster as a ksh clone for the few things that
  | matter in my dot files -- I just want to avoid having to invent a new
  | category for it just to keep it separate from both Ksh (and clones) and
  | other Ash derivatives that don't grow a $RANDOM.

Like most things, attempting to divide the world into two groups, the
goodies and the badies (white hats and black hats) simply does not work.
What you really want is to test each feature that you would like to use
individulally, and see if it works - then your startup will adapt, not
not only to different locations, with different shells, but also without
effort as the shell on a system grows new functionality through upgrades.

The usual technique is something like

	if (eval "some command/syntax you want to test") >/dev/null 2>&1
	then
		: # it works - use it
	else
		: # don't have that feature/whatever, find a workaround
	fi

The subshell is so the test cannot affect the current shell, other than
via the exit status it returns, the eval so you can write possibly invalid
syntax and see if it parses - when that is not a problem, the eval can
get omitted.

So to test if the shell lets "strange" function names be defined, you
can do

	( eval ",() { exit 0; } ; ," ) >/dev/null 2>&1

and test its exit status with "if" "&&" or "||"  and similar for other
features that you care about (return instead of exit would also work.)

For what it is worth, yash & ksh93 (also with $RANDOM) and
dash & bosh (without RANDOM) all do not allow that (status != 0),
whereas bash, zsh and mksh (with $RAMDOM), and the FreeBSD shell (without)
all allow that syntax (exit status 0).

RANDOM does not provide a useful way to distinguish...

I suspect that the same is likely of most other features.   Of course, 30
years ago, the world was both simpler, and more divided.

kre



Home | Main Index | Thread Index | Old Index