[ crosspost to CLA removed ]
On 17.02.2022 22:25, Kenny McCormack wrote:
[...]
But what I'm really wondering about is whether it makes sense to switch to ksh from bash for my day-to-day shell scripting. I'm pretty familiar and comfortable with bash at this point; I'd rather not switch unless there was
a good reason.
My guess would be that it's not necessary if you don't mind the speed degradation of bash and had not yet need for any of the advanced ksh93 features.
The system that I am typing on right now has /usr/bin/ksh as a link to /usr/bin/ksh2020 - which is, presumably, 27 years better than ksh93
If I read what this 2020 thing actually is, I wouldn't bet on that.[*]
And also mind that version "ksh93u+" is from Aug 2012, quite "new".
What has to be said about the quasi-standard ksh93u+ is that it has a
couple nerving bugs in interactive use (that may be considered as being irrelevant if used only for scripting). If you want to switch I'd surely suggest to use the derived version ksh93u+m (see the announcement post
from Marijn Deckker, Dec 2021, in this newsgroup); this works flawless
it seems, the author seems to have spent a lot effort in bug-fixing.
(if you
see what I mean...). I'd like to hear from people knowledgeable on both shells as what kind of advantages ksh has over bash.
Speed, features, always leading inventor of useful new features.[**]
Enumerating the features is cumbersome, since bash was trying to catch
up over the time, and a feature missing in earlier bash releases might
now be part of it. Off the top of my head: FP-arithmetic and a lot of
the C-lib functions, arithmetic for-loop, arithmetic command, command
negation, more [[...]] tests, many variable expansion variants, a lot
of performant builtins, extended patterns are standard, IO-redirections
to seek and skip in files, scope in functions (visibility, signals,
getopts, ...), name references, so called discipline functions (that
can be associated with variables to trigger actions on read/write/...),
data type definitions, extended printf controls, support for shell and
regexp patterns, ANSI quoting, the extremely powerful getopts, and
certainly I forgot to mention many many more.
If you used in your scripts the few bash-specifics (that ksh typically
supports in another form) these programs may break (unless you use #! mechanics).
One thing to also consider for a decision is that bash, as standard
shell and inherent part on Linux systems, will probably be continued,
while I don't know the plans for ksh93u+m (and AT&T's branch ksh93u+
is a dead end anyway, I suppose).
The one that I am aware of is floating point math handled natively in the shell. This is a significant thing, and one I often miss in bash. I see
no particular reason why it could not be implemented in bash.
Indeed. And I am wondering why over that long period of time it's
not yet been implemented in bash, since the syntactic context is
quite localized, mainly in $((...)), ((...)), and for((...)) loops.
In fact,
I've worked up a system where I run "bc" as a co-process that works pretty well. Note that if you Google "floating point in bash", you'll get lots of suggestions to use "bc", but none (AFAICT) mention running it as a co-process. That seems to be my innovation.
LOL. Think about it. In the early 1990's I used ksh88, which did
support co-processes already, but didn't support FP-arithmetic.
What do you think is the straightforward workaround for ksh-users
at that time? ;-)
Janis
[*]
https://en.wikipedia.org/wiki/KornShell :
KornShell, i.e. ksh2020, a "major release for several reasons"
(such as removal of EBCDIC support, dropped support for binary
plugins written for ksh93u+ and removal of some broken math
functions), was released by AT&T, but is not maintained or
supported (by AT&T; wasn't even on release date).
[**] The latter isn't true any more since the labs fired the authors
and discontinued development. If you follow the ksh93u+m path it's a
different situation, though.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)