Announcing: KornShell 93u+m/1.0.7
https://github.com/ksh93/ksh

Here is the seventh ksh 93u+m/1.0 bugfix release. It fixes a hang in
command substitutions when combined with 'exec' and certain redirections.

Further below is an overview of the main changes. For greater detail, see
the NEWS file in the distribution. For complete detail, see the git(1)
commit log, which has full documentation of every significant change.

### HOW TO GET IT ###

Please download the source code tarball from our GitHub releases page:
https://github.com/ksh93/ksh/releases
To build, follow the instructions in README.md or src/cmd/ksh93/README.

Or ask your distribution package manager to upgrade ksh to this version.

### ABOUT KSH ###

KornShell (ksh) is a full-featured and very fast shell script interpreter
and interactive command shell with a distinguished lineage: it is a direct
descendant of the Bourne shell and, like its ancestor, was developed at
AT&T, the birthplace of UNIX. ksh has been open source since 2000.

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
growing the tradition. For now, we are focusing mostly on fixing bugs and
egregious flaws but we also prioritise backward compatibility, performance,
portability, and occasionally adding a feature. Work on ksh 93u+m started in
May 2020, based on the last AT&T stable release, ksh 93u+.

Unique ksh features include discipline functions (every variable expansion
or assignment can trigger a shell function call determining its value),
static scoping of local variables in functions, the ability to define your
own data types, customisable tilde expansion (new in 93u+m), a shell option
for file system case (in)sensitivity detection for pathname expansion and
file name completion (new in 93u+m), and much more.

### CONTRIBUTORS ###

Main ksh 93u+m developers: Martijn Dekker, Johnothan King, hyenias

Direct contributors: Andy Fiddaman, Anuradha Weeraman, atheik, Chase,
Cy Schubert, Govind Kamat, Harald van Dijk, K. Eugene Carlson, Lev
Kujawski, Marc Wilson, Phi, Ryan Schmidt, rymrg, Sterling Jensen,
Trey Valenta, Vincent Mihalkovic

Also includes backported contributions by: David Korn, Glenn Fowler,
Lefteris Koutsofios, Siteshwar Vashisht, Kurtis Rader, Roland Mainz,
Finnbarr P. Murphy, Lijo George, OpenSUSE ksh 93u+ patch authors, Red Hat
ksh 93u+ path authors, Solaris ksh 93u+ patch authors, Debian ksh 93u+
patch authors, Apple ksh 93u+ patch authors, Graphviz maintainers

Many fixes have also been backported from the AT&T 93v- beta as well as the
former AT&T ksh2020 project lead by Kurtis Rader and Siteshwar Vashisht; we
appreciate and benefit from their work. Many thanks also to Siteshwar for
graciously donating his 'ksh93' GitHub organisation account!

### HOW TO GET INVOLVED ###

To report a bug, please open an issue at our GitHub page (see above).
Alternatively, email me at martijn@inlv.org with your report.
To get involved in development, read the brief policy information in
README.md and then jump right in with a pull request or email a patch.
Feel free to use Discussions to introduce yourself to the community.

You can also join the mailing list/Google group at:
https://groups.google.com/g/korn-shell

### MAIN CHANGES between ksh 93u+m/1.0.6 and 93u+m/1.0.7 ###

- Fixed a hang in command substitutions (introduced in 93u+m/1.0.0) that was
triggered when redirecting standard output within a command substitution,
in combination with other factors. E.g., the following no longer hangs:
{ v=$(redirect 2>&1 1>&9); } 9>&1
- Fixed a crash on trying to append an indexed array value to an unset name
reference, e.g.: nameref unsetref; unsetref+=(foo bar). This now produces
a "removing nameref attribute" warning before performing the assignment.
- Fixed: assignments like name=(...) to arrays did not preserve the array
and variable types; similarly, assigning an empty set () to a compound
indexed array caused the -C attribute to be lost.
- Fixed incorrect rejection of the tab key while reading input using the
'read' built-in command.
- Fixed a bug in printf %T: when using dates and times in the past, time
zones for the present were incorrectly used, ignoring historical changes.

### MAIN CHANGES between ksh 93u+m/1.0.5 and 93u+m/1.0.6 ###

- Fixed a serious regression in pathname expansion where quoted wildcard
characters were incorrectly expanded if a pattern contains both a brace
expansion and a variable expansion.
- Fixed a bug where the command to launch a full-screen editor (^X^E in
emacs and 'v' in vi) could cause the wrong command line to be edited
if two shell sessions share a .sh_history file.

### MAIN CHANGES between ksh 93u+m/1.0.4 and 93u+m/1.0.5 ###

- Fixed various bugs causing crashes.
- Fixed many bugs in the emacs and vi line editors, in command completion,
and in file name completion.
- Fixed various bugs in the handling of quotes, backslash escapes and braces
when processing shell glob patterns (e.g. in pathname expansion and 'case').
- ksh now throws a panic and exits if a read error (such as an I/O error)
occurs while trying to read the next command(s) from a running script.
- Fixed many bugs in 'printf' and 'print -f' built-in commands, including:
. Multiple bugs causing incorrect output for relative date specifications,
e.g., printf %T\\n 'exactly 20 months ago' now outputs a correct result.
. More printf bugs with mix and match of % and %x$.
. A data corruption bug when using %B with 'printf -v varname'.
. A bug causing double evaluation of arithmetic expressions.
- Fixed a bug where 'unset -f commandname', executed in a subshell, hides
any built-in command by the same name for the duration of that subshell.
- Fixed ${var/#/string} and ${var/%/string} (with anchored empty pattern)
to work as on mksh, bash and zsh; these are no longer ineffective.
- Fixed incorrect result of array slicing ${array[@]:offset:length} where
'length' is a nested expansion involving an array.
- Command names can now end in ':' as they can on other shells.
- Fixed a spurious syntax error in compound assignments upon encountering a
pair of repeated opening parentheses '(('.
- Fixed spurious syntax error in ${parameter:offset:length}: the arithmetic
expressions 'offset' and 'length' may now contain the operators ( ) & |.
- Fixed a parsing bug in the declaration of .sh.math.* arithmetic functions.
- Fixed nameref self-reference loop detection for more than two namerefs.
- Several improvements to the POSIX compatibility mode.
- Many more minor and/or esoteric bugfixes.

### MAIN CHANGES between ksh 93u+m/1.0.3 and 93u+m/1.0.4 ###

- Fixed multiple scoping-related bugs in the += additive assignment operator.
- A number of crashing bugs have been fixed.
- Various fixes for the Haiku operating system, notably 'ulimit -a' now works.
- Fixed the expansion of out-of-range \n back references in the string part of
${parameter//pattern/string}. For example: v=AB; echo "${v/@(A)B/\0:\1:\2}"
now yields 'AB:A:' instead of 'AB:A:\2'.
- Fixed quoted '!', '^' and '-' within [bracket] expressions in glob patterns;
single or double quotes failed to disable their operator behaviour.
- Fixed a bug introduced on 2021-04-04 that incorrectly allowed 'typeset' to
turn off the readonly and export attributes on a readonly variable.
- In the emacs line editor, the Ctrl+R reverse-search prompt is now visually
distinct from a literal control character ("^R: " instead of "^R").
- In the vi line editor, fixed the behaviour of 'C', 'c$' and 'I' to be
consistent with standard vi(1) and with Bolsky & Korn (1995, p. 121).
- Aliases for many GNU long options have been added to the /opt/ast/bin
built-in commands. Additionally, 'kill -s' now has a --signal long option
alias compatible with the util-linux option.
- Backported support for 'print -u p' from ksh 93v- for compatibility with
scripts written for 93v-/ksh2020 (this is equivalent to 'print -p').

### MAIN CHANGES between ksh 93u+m/1.0.2 and 93u+m/1.0.3 ###

This point release fixes the following:
- An old bug in history expansion (set -H) where any use of the history
comment character caused processing to be aborted as if it were an invalid
history expansion.
- A bug in command line options processing that caused short-form
option equivalents on some built-in commands to be ignored after one use,
e.g., the new read -a equivalent of read -A.
- Ksh freezing or using excessive memory if HISTSIZE is assigned a
pathologically large value.
- A bug that caused ksh in the vi editor mode to crash or produce invalid
completions if ESC = was used at the beginning of a line.

### MAIN CHANGES between ksh 93u+m/1.0.1 and 93u+m/1.0.2 ###

This bugfix release fixes the interactive shell crashing when one of the
predefined aliases (currently 'history' and 'r') is redefined, whether from
a profile/kshrc script or manually. This crash occurred in two scenarios:
1. when redefining and then unsetting a predefined alias;
2. when redefining a predefined alias and then executing a shell script that
does not begin with a #! path.

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
updates.) Despite these bugs I was using ksh as my shell of choice
since the early 1990's.

> 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?

I'm asking because the subset of bugs I stumbled across had often
been (also) in old functionality, and myself using newer features
of ksh that are useful to me and (though not 100% free of bugs -
and which complex software would claim so?) typically just work.

Janis

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:
>> 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

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.

In article <ue3qnr$3omqt$1@dont-email.me>, <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.

You know what they say about opinions.

Everybody's got one.

--
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/God

On Sat, 16 Sep 2023 09:10:28 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <ue3qnr$3omqt$1@dont-email.me>, <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.
>
>You know what they say about opinions.
>
>Everybody's got one.

I don't present mine as fact. Plenty of others do. Plus I've been working
on *nix for 30 years and only twice have I seen anyone try and get clever
with shell scripts , in one case using co-process in bash. In both cases
their code was fragile and didn't cope with edge cases and they'd have been
better off writing it in a language that had far better error handling.
$? and trap simply don't cut it beyond a certain level of complexity.

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.

--
--
user <candycane> is generated from /dev/urandom

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...

--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.

- John Kenneth Galbraith -

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".)

The observation that even simple repeating tasks can be collected in a
imperative language frame, tasks that had there origin as command line
commands, is and was just a consistent view on the shell's abilities
and shell's design.

>
>>> 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.

I cannot guess which ones on that list you have in mind. Almost all bug
fixes I see for "u+m" are fixes of original AT&T ksh, so you say you
haven't used the mentioned Kornshell's features? (I certainly used most
of them over the decades.)

>
> 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.

What later shells (and the POSIX standard) added was builtin features
to make it possible to efficiently work on the growing performance
demands with handled volumes and number or size of handled objects.

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.

(OTOH, if you don't use the post-Bourne shell features it's probably
pointless to discuss.)

Janis

On 16.09.2023 18:56, candycanearter07 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.

Shell is no simple language, it has a lot of pitfalls; beginners should
be carefully trained or guided, or kept away from shell programming!
Knowledge of "other languages" is of limited use to master shell with
all its quirks and dangers. Note also that shell is standard and part
of every Unix system; in the 1990's there was no perl or python in the
commercial standard environments, which was often even forbidden to
be installed by a (very reasonable) security policy or by portability
standards guidelines.

Janis

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."

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sat, 16 Sep 2023 17:27:09 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>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...

If writing code in scripting languages like perl or python is beyond you then
I would suggest you steer clear of any kind of programming and leave it to
people who know what they're doing. People who couldn't hack their way out
of a wet paper bag yet think they can write code in shell explains a lot
of the crap I've seen over the years written by sysadmins.

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.

--
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/Windows

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
>> 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".)

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
languages you'd have been even more confused given we're discussing shell
script.

>> 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.

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].

etc

>> 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!

face <- palm

>(Myself I use shell and never experienced a necessity to switch
>to perl or python.) Awk (a language I extensively also use) is not

I rest my case.

>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 Sun, 17 Sep 2023 00:11:55 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>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."

Where did I say that? BUt its horses for courses. You wouldn't use assembler
to write a GUI app even though its possible and you wouldn't use java to
write a device driver. Why would you use shell to do anything beyond
process control and basic checking when there are much better alternatives?

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?

--
Debating creationists on the topic of evolution is rather like trying to
play chess with a pigeon --- it knocks the pieces over, craps on the
board, and flies back to its flock to claim victory.

On Sun, 17 Sep 2023 15:09:53 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>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.

Looks like I scored a bullseye or you wouldn't be so triggered.

Unfortunately when sys admins write garbage code the dev team in most
companies often ends up picking up the pieces and usually rewriting 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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-16, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <ue3qnr$3omqt$1@dont-email.me>, <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.
>
> You know what they say about opinions.
>
> Everybody's got one.

The version I remember is:

Well, you know, opinions are like assholes: everyone has one.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

In article <20230917122406.211@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-09-16, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> ...
>>
>> You know what they say about opinions.
>>
>> Everybody's got one.
>
>The version I remember is:
>
>Well, you know, opinions are like assholes: everyone has one.

Yup.

--
When polled for who is/was the worst US president, the candidates (i.e. popular responses/suggestions) are usually:
(Andrew) Johnson, Buchanan, or Trump
When polled for who is/was the best US president, the candidates (i.e. popular responses/suggestions) are usually:
FDR, Lincoln, or Trump

On Sun, 17 Sep 2023 15:26:50 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>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?

I would suggest you learn to read basic english first before you accuse others
of being a moron.

Which part of "interpreted languages such as perl or python" confused your
lonely brain cell?

Idiot.

On Sun, 17 Sep 2023 15:58:43 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>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.

Yes, that applies to a lot of places. But a lot of places also have sysadmins
who right garbage code, get upset when it doesn't work and expect others to
fix it when they realise they can't. Not a problem when its a scripting
language but when they try C or even C++ *shudder*...

On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
> 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. [...]

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).
Speed is indeed an issue with shells, though mind; bash is faster than
old Bourne sh (because of built-in functions that avoid costly external
tools/processes), and that Kornshell is a lot faster then bash (as one
of its central runtime optimization design criteria).

>>
>> (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.

I basically agree on that. Though the control constructs frame of the
sh-family (the part that was heavily influenced by the [probably most
formal] Algol[68] language) is still an outstanding clean concept!
It's amazing that in Unix they invented such a language base for stuff
that was formerly handled by simple "command processors".
The ugly stuff, all that cryptic syntax parts, is indeed a "challenge"
for the programmer. Note here, though, that even that ugly part of the
shells' syntax has been made to some degree coherent by the Kornshell
designers (and some made their way into the POSIX sh and other 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.

(These opinions, prejudices, and generalizations can't be sensibly
commented on; I abstain. It certainly doesn't [generally] match with
the various folks that are doing such tasks hereabouts that I've seen.)

>
>> 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].

This is correct. To pick out one prominent example from your list...

Numeric processing. You wouldn't do math, say, algebra with matrix
calculations in shell. But you have to handle numbers and numeric
expressions. That's why (besides the clumsy 'let') the $((...)) has
been introduced in shell to write readable math expressions inside
the parenthesis and use its value. The introduction of ((...)) is
a [syntactically] straightforward ksh extension to use an arithmetic
expression as command to control the program flow in the Algol-frame
with a C/C++ boolean logic of arithmetic types.

Similar with $(...), replacing the old Bourne-sh `...`. It's been
introduced not only to fix inherent problems with nesting and the
optical confusion with single quotes and whatnot. The syntax is also
coherent with the (...) expression. Both forms create sub-processes
(conceptually; may be optimized internally to not spawn a process),
one expands the value for use, the other just runs it.

So, yes, historic reasons lead to an evolution of shells that lead
to what we have now. And any language that is designed from scratch
for specific (other) purposes could be defined with cleaner syntax.
Though given the syntax of some newer language [versions], say C++,
current shell versions are not too bad for the areas where we use
them. (But see also my "beginners" caveat in another post here.)

> [...]
>> suited for the tasks I typically do with shell.
>
> So basically you know essentially squat about real programming yet you're

(Don't understand what "squat about real programming" is supposed to
mean.)

> advocating that shell is great for dev. Got it. Reminds me of people who

(I haven't mentioned "dev" anywhere.)

> only know BASIC and wonder why any other language would ever be needed.

Well, I cannot speak about "other people" (as you seem to be able,
as above, here again).

I can only speak for myself (if that's what helps you understanding
the area better); I started using shells from the Bourne family on
a regular basis around 1990. At that time I could fluently program
software solutions in more than half a dozen high-level programming
languages from that time (plus a couple assembler). In the following
decades a couple more languages filled my proficiency list. There was
never a reason to switch from shell (for the tasks suited for shells)
to other languages; also later when (e.g.) perl got more mature and I
used it for (a few) professional tasks [in environments where it was
possible to use] where it was sensible to use it - it was unnecessary.

>
>>> 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.

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".

That's not much substance. - Good luck, anyway.

Janis

On Mon, 18 Sep 2023 12:05:29 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>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).

Perl yes, though arguably first as an improved awk. Python I don't know. I
suspect it was a clean sheet language that he wanted certain functionality in
that proved useful as a command line and scripting language too and better
than Perl for most things.

>> The list posted a few days ago.
>
>For the second time you didn't answer that question (which was not

I'm not going to repost what he posted. Its easy to find.

>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".

They're better for most scripting tasks that require any significant logic
and/or mathematics. I'm not claiming they're better for just doing basic unix
housekeeping and admin tasks, that would be silly. If you want to do "ls -l"
and pipe it to a file obviously you'd use shell. But if you need to go through
every file in a directory, sum up some columns in them and print a formatted
subtotalling and totalled result you'd at least use awk if not perl/python.
You sure as hell wouldn't do it all in shell (though you probably could).