oksh VS DragonFlyBSD

David Korn's ksh93 was passed on to a new set of developers, who attempted to release a new version; AT&T rolled back these changes due to performance problems which raised questions of support status. It does appear that ksh93 development has resumed, and a new version was released late last year.

https://github.com/ksh93/ksh/releases

The independent pdksh spawned mksh, which is the default shell used in Android (as it has a BSD license); mksh appears to be very much active.

http://www.mirbsd.org/mksh.htm [https site has cert problems]

OpenBSD also forked oksh from pdksh. This is certainly well-maintained.

https://github.com/ibara/oksh

I don't know if this is helpful or just annoying unsolicited "advice"

Anyway, for those of us who like openbsd ksh(all two of us) which is derived from pdksh. there is the project oksh.

https://github.com/ibara/oksh

I like oksh: https://github.com/ibara/oksh

...and that ksh descended from pdksh, and is distributed as the oksh portable project here:

https://github.com/ibara/oksh

The MirBSD Korn Shell also descended from pdksh, and it can be found here:

http://www.mirbsd.org/mksh.htm

I don't know about the feature differences and code quality between these two; they both implement most of ksh88, and a small amount of ksh93.

I prefer mksh when I need something more than a POSIX shell.

Brian Callahan publishes a portable version here: https://github.com/ibara/oksh

Porting from OpenBSD, look for the portable versions and their compat layer. https://github.com/ibara/oksh/blob/master/portable.h

Lots of Amiga concepts live on today with DragonflyBSD.

https://www.dragonflybsd.org/

And it’s shockingly performant (on par with Linux, sometimes even better), given the tiny development team.

Messaging passing, etc are core Amiga ideas that exist today only in Dfly.

Love FreeBSD but ...

Really wish there wasn't a split between FreeBSD & Matt Dillon 18-years ago (DragonflyBSD), since DragonflyBSD is so strong and yet FreeBSD hasn't benefited from it's innovations.

https://www.dragonflybsd.org

There are three things I expect to find in mailing list discussions before going off and reading them:

* Someone suggests that the kernel return EINVAL for null or zero-length argument vector. Someone else then comes up with a mad but very real mainstream program that relies upon the system call succeeding.

* Someone points out that the SUS requires that argv[0] be non-null. Someone else tries to weasel a difference between "shall" and "should", overlooking the SUS rationale that the leeway given is in the string contents, not that it is permitted to be outright null.

* Someone suggests in all seriousness that this behaviour be retained for historical compatibility.

For reference:

* FreeBSD just returns EINVAL for a zero-length argument vector, https://github.com/freebsd/freebsd-src/commit/773fa8cd136a57... . This came from OpenBSD.

* A null argument vector has been EFAULT in FreeBSD since 2004, when someone noticed that the manual disallowed this, https://github.com/freebsd/freebsd-src/commit/7700eb86e7740c... .

* DragonFly BSD has been fixing up a zero-length argument vector by adding in a dummy non-null argv[0] since 2005, https://github.com/DragonFlyBSD/DragonFlyBSD/commit/66be6566... . It introduced EFAULT for a null argument vector at the same time.

* Illumos has returned EFAULT for a null argument vector since at least the point when it went open-source in 2005.

I find it remarkably rude to name your business product the same as a long-established open-source project.

Ay wanna give dragonflybsd a go? Link

DragonflyBSD: Forked from FreeBSD 4.8; amongst other things, provides HAMMER, a "high performance filesystem with built-in mirroring and historic access functionality", and virtual kernels.

FreeBSD, NetBSD, and OpenBSD all have a ksh(1) descending from pdksh, while DragonFlyBSD does not implement any ksh.