On Thu, Feb 05, 2015 at 01:25:41AM -0600, Rob Landley wrote:
> On 02/03/2015 06:09 PM, Isaac Dunham wrote:
> > Hello,
> > I noticed a comment in landley.net/notes.html about missing stuff in
> > bash 2.05b (set -o pipefail, jobs).
> > My local build of bash 2.05b, configured with 
> > ./configure --disable-gnu-malloc
> > has jobs; I guess this is --enable-job-control.
> > In doc/FAQ, it mentions set -o pipefail as a new feature in ksh-93
> > that isn't in bash.
> 
> So it was a new feature that wasn't in bash in 1993? (Linux was started
> in 1991, bash 2.05 was the version in Red Hat 9 circa 2003. That's ten
> years after that, but more than ten years _ago_ now...)

No, it's a feature that ksh 93g introduced in ~1998, and that bash 2.05
documented as not being supported yet without mentioning which ksh93
it came from.

ksh-93 does not just refer to the Korn shell as it stood in 1993.
It means the development series that was first released in 1993,
which is still getting new features after ~3 relicenses and 22 years.
(It went from proprietary to an in-house license to CPL to EPL.)
Releases are numbered as 93<a> where <a> is a lowercase letter.
Of course, only ksh users bother distinguishing between versions of
ksh93.

Currently it's at 93v, which features several small bugfixes and some
experimental support for printing compound variables in JSON format.

This reminds me:
Reading the ast-developers list, I found out that the "OpenSolaris
Busybox" (mentioned in roadmap.html) actually made some progress.
However, it's not exactly what or where you'd expect.
It became known as "ast busybox", and it means more-or-less
"ksh93 with as many commands from ast-open as possible builtin."

I saw a comment on the ast-developers list years ago indicating that
they saw the license as a possible "in":
http://lists.research.att.com/pipermail/ast-developers/2012q3/001519.html

That said, I would strongly advise against going digging through
ksh93 and ast-open: not for licensing reasons, but because it is
*incredibly* convoluted-you would need to
 -figure out how mamake works/fails to work; they managed to write 
  a build system that's more intransigent than autohell by using
  a dozen shell scripts for added indirection
 -figure out sfio; after coming up with C, the guys at Bell Labs
  decided to rewrite stdio to be more robust, but made it nearly as
  tightly tied into the internals of libc (if I understand correctly).
 -skip over miles of optimization for speed at the expense of size,
  such as the shell script compiler

Also, they have many features that not even the GNU developers have
caught up with yet.

Thanks,
Isaac Dunham

_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to