3 ms·
> However, the MirBSD Korn shell is one of the most lively shells for development activity, the latest release being in October of 2020. https://lists.gnu.org/
by abathur 5y ago
> However, the MirBSD Korn shell is one of the most lively shells for development activity, the latest release being in October of 2020.
https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003.html https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003...
- chasil 5y agoAs said, far more active. bash 5.0: https://www.osnews.com/story/129062/bash-5-0-released/ https://www.osnews.com/story/129062/bash-5-0-released/ 2019-01-08 MirBSD Korn 2020: Oct 31, 2020 mksh-R59c May 16, 2020 mksh-R59b Apr 14, 2020 mksh-R59 Mar 27, 2020 mksh-R58 Mar 1, 2019 mksh-R57
- abathur 5y agoAs said: > the MirBSD Korn shell is one of the most lively shells for development activity, the latest release being in October of 2020 I.e., you suggested the measure is release recency, not cadence. And after I pointed out that bash (sorry, BASH) has a more-recent release, you're moving the goalposts. Anyways. It doesn't matter. Love the shell(s) you love; hate the shell(s) you hate. You don't need a quantitative basis. They can release as often or as rarely as they like with little impact on whether they're good shells or not. Also: https://github.com/oilshell/oil/branches/all?query=release%2F https://github.com/oilshell/oil/branches/all?query=release%2...
- chasil 5y agoAs much of the scripting that I am required to maintain emerged from HP-UX, the "POSIX" shell on my legacy platform emerged from Korn (and I have the manual page to prove it - the text of the HP-UX "POSIX" shell manual page includes arrays and a number of other Korn features). The reason that the POSIX shell is not Korn is the existence of Microsoft Xenix, where the maximum size of the code/text segment is 64k. Debian chose the POSIX standard for precisely this reason: a minimal text segment. One particular thing that I like about Korn is this: function getv { nameref var="$1"; shift; print "$@"; read var; } This cannot be done with (my versions of) "bash." ShellCheck flips a gasket over this (legal) syntax. I will post some of my scripting that uses this feature if you have interest.