But when AT&T terminated development in 2020, ksh was left buggy and >unreliable. ksh 93u+m aims to fix this situation whilst maintaining and
On Fri, 15 Sep 2023 15:37:37 +0100 Martijn Dekker
<martijn@inlv.demon.nl> wrote:
But when AT&T terminated development in 2020, ksh was left buggy
and unreliable. ksh 93u+m aims to fix this situation whilst
maintaining and
I used it back in the day and never found it buggy or unreliable.
No doubt as with all mature software where the devs need to justify
their continued update of it, a load of mostly useless features were
added which they found interesting to do and added a load of bugs in
the process.
On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:
On Fri, 15 Sep 2023 15:37:37 +0100 Martijn Dekker
<martijn@inlv.demon.nl> wrote:
But when AT&T terminated development in 2020, ksh was left buggy
and unreliable. ksh 93u+m aims to fix this situation whilst
maintaining and
I used it back in the day and never found it buggy or unreliable.
Uh-oh! - There were bugs, and even most obvious ones had been left
unfixed for years. (So glad that Martijn & Co. provides reliable
No doubt as with all mature software where the devs need to justify
their continued update of it, a load of mostly useless features were
added which they found interesting to do and added a load of bugs in
the process.
Weren't David and Glenn working on ksh's features until they left?
What were (in your opinion) these "mostly useless features" that
you have in mind?
Seems to me far too many people try and use shell script way beyond what it was intended to do - ie navitage the file system, link commands together and job control - and use it where they'd be far better off simply using perl or python (or even awk) which leads shell authors to bung in features no sane person in their right mind would ever need, never mind use.
On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
Seems to me far too many people try and use shell script way beyond what it >> was intended to do - ie navitage the file system, link commands together and >> job control - and use it where they'd be far better off simply using perl or >> python (or even awk) which leads shell authors to bung in features no sane >> person in their right mind would ever need, never mind use.
I agree, being so simple and being *right there* draws in beginners who
don't know other languages I think.
On Fri, 15 Sep 2023 17:46:39 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:
I used it back in the day and never found it buggy or unreliable.
Uh-oh! - There were bugs, and even most obvious ones had been left
unfixed for years. (So glad that Martijn & Co. provides reliable
I never came across any. But then I don't use shell as a substitute interpreted
language.
No doubt as with all mature software where the devs need to justify
their continued update of it, a load of mostly useless features were
added which they found interesting to do and added a load of bugs in
the process.
Weren't David and Glenn working on ksh's features until they left?
What were (in your opinion) these "mostly useless features" that
you have in mind?
Look at the list of updates he listed in that post. I looked at them and couldn't see a time at which I'd ever use a single one.
Seems to me far too many people try and use shell script way beyond what it was intended to do - ie navitage the file system, link commands together and job control -
and use it where they'd be far better off simply using perl or
python (or even awk)
which leads shell authors to bung in features no sane
person in their right mind would ever need, never mind use.
On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
Seems to me far too many people try and use shell script way beyond
what it
was intended to do - ie navitage the file system, link commands
together and
job control - and use it where they'd be far better off simply using
perl or
python (or even awk) which leads shell authors to bung in features no
sane
person in their right mind would ever need, never mind use.
I agree, being so simple and being *right there* draws in beginners who
don't know other languages I think.
On Fri, 15 Sep 2023 17:46:39 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
Uh-oh! - There were bugs, and even most obvious ones had been left
unfixed for years. (So glad that Martijn & Co. provides reliable
I never came across any. But then I don't use shell as a substitute interpreted
language.
beyond and way in languages clear doing. yet over writing would who a
the you leave out shell like of People think the code suggest know wet
crap then it explains perl any who they years in you what paper I've to a >python or of hack kind write couldn't by can written is programming their >code sysadmins. scripting steer they're bag seen lot If I people of of
In article <ue4mom$3t6o2$2@dont-email.me>,
candycanearter07 <no@thanks.net> wrote:
On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
Seems to me far too many people try and use shell script way beyond what it >>> was intended to do - ie navitage the file system, link commands together and
job control - and use it where they'd be far better off simply using perl or
python (or even awk) which leads shell authors to bung in features no sane >>> person in their right mind would ever need, never mind use.
I agree, being so simple and being *right there* draws in beginners who >>don't know other languages I think.
Poppycock.
I especially love the phrase (quoted above): simply using perl or python
Yeah, right...
On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
On Fri, 15 Sep 2023 17:46:39 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:
I used it back in the day and never found it buggy or unreliable.
Uh-oh! - There were bugs, and even most obvious ones had been left
unfixed for years. (So glad that Martijn & Co. provides reliable
I never came across any. But then I don't use shell as a substitute >interpreted
language.
Not perfectly sure I understand the "a substitute interpreted language"
here correctly. For sure a shell is (and always was; since Bourne) an >interpreted language. (And David Korn certainly, and correctly, named
ksh as what it was intended, a "Command and Programming Language".)
Seems to me far too many people try and use shell script way beyond what it >> was intended to do - ie navitage the file system, link commands together and
job control -
(This appears to me to be a very limited application view.) - Are you
saying here that already in 1988 (or 1993 ?) Korn (et al.) provided >extensions to Bourne sh that were unnecessary? - You think a shell is
(and should be) just a command line processor (like MS cmd, or so)?
Even Bourne sh had while/for/case/if/... and signal traps.
It's really hard to understand (from your statements) your view what
you think a shell should provide and what it shouldn't. Some examples
would help.
and use it where they'd be far better off simply using perl or
python (or even awk)
Perl and python are non-standard, and also not simple, you have to
learn these new languages. There should be a reason to learn them!
(Myself I use shell and never experienced a necessity to switch
to perl or python.) Awk (a language I extensively also use) is not
suited for the tasks I typically do with shell.
which leads shell authors to bung in features no sane
person in their right mind would ever need, never mind use.
Before diving into the details it would be good to know whether you
are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
and POSIX sh.
On 2023-09-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Fri, 15 Sep 2023 17:46:39 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
Uh-oh! - There were bugs, and even most obvious ones had been left >>>unfixed for years. (So glad that Martijn & Co. provides reliable
I never came across any. But then I don't use shell as a substitute >interpreted
language.
Basically ...
"Bugs that do not affect me do not exist. People who run into bugs are
using the software wrong. Nobody should ever work on bugs that don't
affect me, or features that I don't personally intend to use."
A substitute for interpreted languages such as perl or python. Ie easy to >write with a lot of functionality but slow as hell. If i'd said scripting
In article <ue74ag$dths$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed >out:
....
beyond and way in languages clear doing. yet over writing would who a
the you leave out shell like of People think the code suggest know wet
crap then it explains perl any who they years in you what paper I've to a >>python or of hack kind write couldn't by can written is programming their >>code sysadmins. scripting steer they're bag seen lot If I people of of
Someone just didn't get enough love as a child.
They say that people like this weren't breast-fed long enough (if at all). >That explains a lot.
Unfortunately when sys admins write garbage code the dev team in most companies often ends up picking up the pieces and usually rewriting it.
In article <ue754p$e1uf$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed >out:
....
A substitute for interpreted languages such as perl or python. Ie easy to >>write with a lot of functionality but slow as hell. If i'd said scripting
Do you want to explain to this moron that both of the P's he's so fond of >are, get this, interpreted languages?
Or do I have to do it?
On 2023-09-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
Unfortunately when sys admins write garbage code the dev team in most
companies often ends up picking up the pieces and usually rewriting it.
Alternatively:
1. Sysadmins are forced to write code around applications that are buggy
or don't do everything that is required, don't report information
in good ways, or don't interoperate.
2. Sysadmins are valuable team members who identify a need, and
prototype a working solution.
3. Sysadmins are the only solution providers in companies without a
"dev team" which is, by my estimation, most companies.
On Sat, 16 Sep 2023 23:46:04 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
On Fri, 15 Sep 2023 17:46:39 +0200
Not perfectly sure I understand the "a substitute interpreted language"
here correctly. For sure a shell is (and always was; since Bourne) an
interpreted language. (And David Korn certainly, and correctly, named
ksh as what it was intended, a "Command and Programming Language".)
A substitute for interpreted languages such as perl or python. Ie easy to write with a lot of functionality but slow as hell. [...]
(This appears to me to be a very limited application view.) - Are you
saying here that already in 1988 (or 1993 ?) Korn (et al.) provided
extensions to Bourne sh that were unnecessary? - You think a shell is
(and should be) just a command line processor (like MS cmd, or so)?
Even Bourne sh had while/for/case/if/... and signal traps.
Yes it does, and its as ugly and hacky as fuck with idiotic syntactic
quirks just like most shells.
No sensible dev uses shell beyond kicking
something off and maybe simply monitoring. Sysops however whom mostly can't code well to save their lives seem to think programming in shell is normal because often thats all they know.
It's really hard to understand (from your statements) your view what
you think a shell should provide and what it shouldn't. Some examples
would help.
Sub shell, co processes, process substitution, lists, idiotic numeric
syntax with (( )) everywhere (not to be confused with () or [[]] !) and
make sure you use your whitespace correctly because [hacky historical reasons].
[...]
suited for the tasks I typically do with shell.
So basically you know essentially squat about real programming yet you're
advocating that shell is great for dev. Got it. Reminds me of people who
only know BASIC and wonder why any other language would ever be needed.
which leads shell authors to bung in features no sane
person in their right mind would ever need, never mind use.
Before diving into the details it would be good to know whether you
are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
and POSIX sh.
The list posted a few days ago.
On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
A substitute for interpreted languages such as perl or python. Ie easy to
write with a lot of functionality but slow as hell. [...]
Okay, I see where you're coming from. A few comments...
The argument should probably be the other way round; perl and python
(for reasons we may leave alone for the moment) are [maybe] meant as >substitute for shell (where shells were here earlier as inherent part
of the Unixes).
The list posted a few days ago.
For the second time you didn't answer that question (which was not
about the list). - From this post I infer that you opinion is to
not use shell for (which?) tasks. That perl and python are "better".
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 360 |
Nodes: | 16 (2 / 14) |
Uptime: | 129:11:45 |
Calls: | 7,686 |
Files: | 12,828 |
Messages: | 5,711,155 |