Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is ksh93 (or 2020) really better than bash? (Was: awk functionality not in ksh93)
102 views
Skip to first unread message
Kenny McCormack
Feb 17, 2022, 4:25:24 PM2/17/22
to
In article <87fsohx...@axel-reichert.de>,
Axel Reichert <ma...@axel-reichert.de> wrote:
...
>While searching here and there on the web, I stumbled again across
>ksh93, which was advertised back then with
>
> The new version of ksh has the functionality of other scripting
> languages such as awk, icon, perl, rexx, and tcl. For this and many
> other reasons, ksh is a much better scripting language than any of the
> other popular shells.
>
>When I saw that it comes with floating point arithmetic, arrays (indexed
>and associative) the questions occured to me how true the rather bold
>claim quoted above is.
I wonder about that. I doubt I'd have to work very hard to come up with
something that I can do in GAWK that can't be done in ksh93.
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.
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 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.
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. 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.
--
Kenny, I'll ask you to stop using quotes of mine as taglines.
- Rick C Hodgin -
Axel Reichert <ma...@axel-reichert.de> wrote:
...
>While searching here and there on the web, I stumbled again across
>ksh93, which was advertised back then with
>
> The new version of ksh has the functionality of other scripting
> languages such as awk, icon, perl, rexx, and tcl. For this and many
> other reasons, ksh is a much better scripting language than any of the
> other popular shells.
>
>When I saw that it comes with floating point arithmetic, arrays (indexed
>and associative) the questions occured to me how true the rather bold
>claim quoted above is.
I wonder about that. I doubt I'd have to work very hard to come up with
something that I can do in GAWK that can't be done in ksh93.
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.
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 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.
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. 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.
--
Kenny, I'll ask you to stop using quotes of mine as taglines.
- Rick C Hodgin -
Janis Papanagnou
Feb 17, 2022, 5:38:39 PM2/17/22
to
[ crosspost to CLA removed ]
On 17.02.2022 22:25, Kenny McCormack wrote:
> [...]
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.
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
> 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.
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
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.
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.
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.
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.
Janis Papanagnou
Feb 18, 2022, 6:05:45 AM2/18/22
to
On 17.02.2022 23:38, Janis Papanagnou wrote:
> On 17.02.2022 22:25, Kenny McCormack wrote:
>> 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? ;-)
BTW, I was astonished about your statement that Google had no entries.
> On 17.02.2022 22:25, Kenny McCormack wrote:
>> 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? ;-)
so I searched Google Groups for this newsgroup and "co-process" and
stumbled across the post/reply I appended below, dated Aug 7, 2004.
It is probably not the first post on that topic and other folks have
certainly used that co-process principle in context with bc before
(as I did in the 1990's) without posting about it, but at least it
seems to stem from a time back when bash didn't support it.
Janis
--- quote begin ---
JQ wrote:
> Would someone be so kind as to explain coprocesses? I don't know if
> bash now supports them of if it's still in Korn's domain. I've never
> quite understood where to best make use and practice of them.
You may view them as providers for external services that are available
to your process.
Say you have some powerful external service like bc's multiple precision
integer arithmetic that you constantly want to use. Start the co-process
and whenever you have a calculation send a message to the coprocess and
get the answer.
You may also use it if you want to provide some new user interface to an
existing program. You take the user input, maybe manipulate the data,
then send it to the coprocess, get the response, optionally change/format
the output to your needs.
The syntax to use it, if not already known to you, is
bc |& # create coprocess 'bc'
while read query?"Enter your data: "
do
print -p "${query}" # send message to coprocess
read -p response # receive response from coprocess
done
My version of bash (2.05) seems to not support coprocesses, at least not
with the ksh syntax.
HTH
Janis
--- quote end ---
John McCue
Feb 18, 2022, 10:35:08 AM2/18/22
to
trimmed followups to comp.lang.awk
In comp.unix.shell Kenny McCormack <gaz...@shell.xmission.com> wrote:
<snip>
> 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.
Depends, will you ever write scripts for any of the BSDs
or a proprietary UNIX ?
If so you may want to use ksh. Otherwise it does not
matter.
>
> 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 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.
YYMV on that one, OpenBSD defaults to a ksh88 clone,
AIX defaults to ksh88. NetBSD seems to default to a ksh
look-alike and the same now seems to be true for FreeBSD.
shell scripts assuming ksh88.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
In comp.unix.shell Kenny McCormack <gaz...@shell.xmission.com> wrote:
<snip>
> 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.
or a proprietary UNIX ?
If so you may want to use ksh. Otherwise it does not
matter.
>
> 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 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.
AIX defaults to ksh88. NetBSD seems to default to a ksh
look-alike and the same now seems to be true for FreeBSD.
>
> 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. 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.
I use bc(1) when I need floating point math since I write
> 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. 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.
shell scripts assuming ksh88.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
Christian Weisgerber
Feb 18, 2022, 2:30:10 PM2/18/22
to
On 2022-02-18, John McCue <jmc...@magnetar.hsd1.ma.comcast.net> wrote:
> Depends, will you ever write scripts for any of the BSDs
> or a proprietary UNIX ?
>
> If so you may want to use ksh.
POSIX sh is the much better bet there.
> Depends, will you ever write scripts for any of the BSDs
> or a proprietary UNIX ?
>
> If so you may want to use ksh.
> YYMV on that one, OpenBSD defaults to a ksh88 clone,
> AIX defaults to ksh88. NetBSD seems to default to a ksh
> look-alike and the same now seems to be true for FreeBSD.
out of the box.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Axel Reichert
Feb 18, 2022, 5:53:36 PM2/18/22
to
Janis Papanagnou <janis_pa...@hotmail.com> writes:
> use the derived version ksh93u+m (see the announcement post from
> Marijn Deckker, Dec 2021, in this newsgroup)
... which was also the one I had in mind when asking.
> use the derived version ksh93u+m (see the announcement post from
> Marijn Deckker, Dec 2021, in this newsgroup)
Axel
John McCue
Feb 18, 2022, 9:31:04 PM2/18/22
to
Christian Weisgerber <na...@mips.inka.de> wrote:
<snip>
<snip>
> No, FreeBSD has a POSIX sh and does not ship with anything ksh-ish
> out of the box.
Was not sure about FreeBSD with its shell, good to know.
> out of the box.
Kenny McCormack
Feb 19, 2022, 2:25:58 AM2/19/22
to
In article <supkp2$nsn$1...@dont-email.me>,
It is hard to imagine a less relevant point in the context of the thread
topic.
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Rorschach
topic.
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Rorschach
0 new messages