Announcing: KornShell 93u+m/1.0.0
https://github.com/ksh93/ksh
_ _ ___ _____ ___ ___ ___
| | _____| |__ / _ \___ / _ _ _ _ __ ___ / / | / _ \ / _ \
| |/ / __| '_ \ | (_) ||_ \| | | |_| |_| '_ ` _ \ / /| || | | | | | |
| <\__ \ | | | \__, |__) | |_| |_ _| | | | | |/ / | || |_| | |_| |
|_|\_\___/_| |_| /_/____/ \__,_| |_| |_| |_| |_/_/ |_(_)___(_)___/

It may have been exactly a decade since the last one, but here it is at
last: a proper new ksh release. :) Many thanks to all contributors for
their hard work! Compared to an unpatched ksh 93u+ 2012-08-01, this
release has roughly a thousand bugs fixed. It incorporates a fair number
of enhancements as well.

This being an initial release, not all known bugs have been worked out
yet. Let's hope this release will rekindle interest and attract more bug
hunters.

### CONTRIBUTORS ###

Work on ksh 93u+m started in May 2020.
Main developers: Martijn Dekker, Johnothan King, hyenias

Direct contributors: Andy Fiddaman, Anuradha Weeraman, atheik, Chase,
Govind Kamat, Harald van Dijk, K. Eugene Carlson, Lev Kujawski, Marc
Wilson, Ryan Schmidt, 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

Many fixes have also been backported from the AT&T 93v- beta as well as
the former 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 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 ksh93 to this version.

### 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. See the
TODO file in the top-level directory for a to-do list.

### MAIN CHANGES between ksh 93u+ 2012-08-01 and 93u+m/1.0.0 ###

Roughly a thousand bugs have been fixed, including many serious/critical
bugs. See the NEWS file for more information, and the git commit log for
complete documentation of every fix. Incompatible changes have been
minimised, but not at the expense of fixing bugs. For a list of
potentially incompatible changes, see src/cmd/ksh93/COMPATIBILITY.

Though there was a "no new features, bugfixes only" policy, some new
features were found necessary, either to fix serious design flaws or to
complete functionality that was evidently intended, but not finished.
Below is a summary of these new features.

New command line editor features:

- The forward-delete and End keys are now handled as expected in the
emacs and vi built-in line editors.

- In the vi and emacs line editors, repeat counts can now also be used for
arrow keys and the forward-delete key, e.g., <ESC> 7 <left-arrow> works.

- Various keys on extended PC keyboards are now handled as expected in the
emacs and vi built-in line editors.

New shell language features:

- Pathname expansion (a.k.a. globbing) now never matches the special names
'.' (current directory) and '..' (parent directory). This change makes a
pattern like .* useful; it now matches all hidden files (dotfiles) in the
current directory, without the harmful inclusion of '.' and '..'.

- Tilde expansion can now be extended or modified by defining a
..sh.tilde.get
or .sh.tilde.set discipline function. See the manual for details.

- The &>file redirection shorthand (for >file 2>&1) is now available for all
scripts and interactive sessions and not only for profile/login scripts.

- Arithmetic expressions in native ksh mode no longer interpret a number
with a leading zero as octal in any context. Use 8#octalnumber instead
(e.g. 8#400 == 256). Arithmetic expressions now also behave identically
within and outside ((...)) and $((...)). If the POSIX mode is turned on,
a leading zero now denotes an octal number in all arithmetic contexts.

New features in built-in commands:

- Usage error messages now show the --help/--man self-documentation options.

- Path-bound built-ins (such as /opt/ast/bin/cat) can now be executed by
invoking the canonical path, so the following will now work as expected:
$ /opt/ast/bin/cat --version
version cat (AT&T Research) 2012-05-31

- 'cd' now supports an -e option that, when combined with -P, verifies
that $PWD is correct after changing directories; this helps detect
access permission problems. See:
https://www.austingroupbugs.net/view.php?id=253

- 'command -x' now looks for external commands only, skipping built-ins.
In addition, its xargs-like functionality no longer freezes the shell on
Linux and macOS, making it effectively a new feature on these systems.

- 'printf' now supports a -v option as in bash. This assigns formatted
output directly to variables, which is very fast and will not strip
final newline (\n) characters.

- 'redirect' now checks if all arguments are valid redirections before
performing them. If an error occurs, it issues an error message instead
of terminating the shell.

- 'return', when used to return from a function, can now return any
status value in the 32-bit signed integer range, like on zsh. However,
due to a traditional Unix kernel limitation, $? is still trimmed to its
least significant 8 bits whenever a shell or subshell exits.

- 'suspend' now refuses to suspend a login shell, as there is probably no
parent shell to return to and the login session would freeze.

- 'test'/'[' now supports all the same operators as [[ (including =~,
\<, \>) except for the different 'and'/'or' operators. Note that
'test'/'[' remains deprecated due to its unfixable pitfalls;
[[ ... ]] is recommended instead.

- 'times' now gives high precision output in a POSIX compliant format.

- 'type'/'whence': Two bash-like flags were backported from ksh 93v-:
- 'whence -P/type -P' is an alias to the existing -p flag.
- 'whence -t/type -t' will print only the type of a command in a
simple format that is designed to be easy to use for scripts.

- 'typeset' has a new '-g' flag that forces variables to be created or
modified at the global scope regardless of context, as on bash 4.2+.

- 'typeset' now gives an informative error message if an incompatible
combination of options is given.

- 'ulimit': Added three options inspired by bash:
- 'ulimit -k' sets the maximum number of kqueues.
- 'ulimit -P' sets the maximum number of pseudo-terminals.
- 'ulimit -R' sets the maximum time in microseconds a real-time process
can run before blocking.
Note that not all operating systems support the limits set by these
options.

- 'whence -v/-a' now reports the location of autoloadable functions.

New features in shell options:

- When the -b/--notify shell option is on and the vi or emacs/gmacs shell
line editor is in use, 'Done' and similar notifications from completed
background jobs are now inserted directly above the line you're typing,
without affecting your command line display.

- A new --functrace long-form shell option causes the -x/--xtrace option's
state and the DEBUG trap action to be inherited by function scopes
instead
of being reset to default. Changes made to them within a function scope
still do not propagate back to the parent scope. Similarly, this option
also causes the DEBUG trap action to be inherited by subshells.

- A new --globcasedetect shell option is added on operating systems where
we can check for a case-insensitive file system (currently Linux, macOS,
QNX 7.0+, and Windows/Cygwin). When this option is turned on, pathname
expansion (globbing), as well as tab completion on interactive shells,
automatically become case-insensitive depending on the file system.
This is separately determined for each pathname component.

- Enhancement to -G/--globstar: symbolic links to directories are now
followed if they match a normal (non-**) glob pattern. For example, if
'/lnk' is a symlink to a directory, '/lnk/**' and '/l?k/**' now work as
you would expect.

- The new --histreedit and --histverify options modify history expansion
(--histexpand). If --histreedit is on and a history expansion fails, the
command line is reloaded into the next prompt's edit buffer, allowing
corrections. If --histverify is on, the results of a history
expansion are
not immediately executed but instead loaded into the next prompt's edit
buffer, allowing further changes.

On Mon, 1 Aug 2022 22:40:39 +0200
Martijn Dekker <martijn@inlv.demon.nl> wrote:
>It may have been exactly a decade since the last one, but here it is at
>last: a proper new ksh release. :) Many thanks to all contributors for

The ship sailed long ago, arrived at its destination, did a round the
world tour and was scrapped. Everyone uses bash or tcsh now unless there's
a legacy reason not to.

>Roughly a thousand bugs have been fixed, including many serious/critical

Rather worrying there were that many.

muttley wrote:

> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>>It may have been exactly a decade since the last one, but here it is at
>>last: a proper new ksh release. :) Many thanks to all contributors for
>
> The ship sailed long ago, arrived at its destination, did a round the
> world tour and was scrapped. Everyone uses bash or tcsh now unless there's
> a legacy reason not to.

Maybe some people prefer ksh? I mean, I bet the devs do, at the very least.

>>Roughly a thousand bugs have been fixed, including many serious/critical
>
> Rather worrying there were that many.

Indeed. That's almost 2 every week for 10 years.

--
What value is a bar of gold to a man dying of thirst in the desert?

On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:

> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>
> > It may have been exactly a decade since the last one, but here it is
> > at last: a proper new ksh release. :) Many thanks to all
> > contributors for
>
> The ship sailed long ago, arrived at its destination, did a round the
> world tour and was scrapped. Everyone uses bash or tcsh now unless
> there's a legacy reason not to.

I'm not so sure about tcsh being all that popular. While it makes for
a decent interactive shell, it's a bad one for scripting because of its
many unpredictable/undefined behaviors.

The one shell that I see as being on the rise in terms of popularity
nowadays is zsh, even though that too is mainly because of its features
as an interactive shell, because ultimately, zsh is not
POSIX-compatible — it does have a Bourne-compatible mode when invoked
as "sh", though.

I myself generally write my scripts in the most portable way — i.e.
compliant with POSIX and avoiding any shell-specific features as much as
possible — and I prefer GNU Bash. <shrug>

Your 1.6-times-kilometerage may vary. ;)

--
With respect,
= Aragorn

Aragorn <thorongil@telenet.be> writes:
>On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>>
>> > It may have been exactly a decade since the last one, but here it is
>> > at last: a proper new ksh release. :) Many thanks to all
>> > contributors for =20
>>=20
>> The ship sailed long ago, arrived at its destination, did a round the=20
>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>> there's a legacy reason not to.
>
>I'm not so sure about tcsh being all that popular. While it makes for
>a decent interactive shell, it's a bad one for scripting because of its
>many unpredictable/undefined behaviors.

The only people in my experience that use tcsh are
RTL designers and verification engineers. It's quite common in the
Synoposys/Cadence world,
primarily because both of those software packages originated on
SunOS, pre-Solaris, which was based on BSD.

I think mutt would be surprised at the extent to which
ksh is still used.

Follow-ups trimmed to comp.unix.shell

In comp.unix.shell muttley@dastardlyhq.com wrote:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>>It may have been exactly a decade since the last one, but here it is at
>>last: a proper new ksh release. :) Many thanks to all contributors for
>
> The ship sailed long ago, arrived at its destination, did a round the
> world tour and was scrapped.

I miss the meaning of this.

> Everyone uses bash or tcsh now unless there's
> a legacy reason not to.

No, maybe everyone on Linux, but there are other UNIX
systems and ksh is used on them. ksh is the default
shell for AIX.

if you want portable scripts, do not use bashisms.

>
>>Roughly a thousand bugs have been fixed, including
>>many serious/critical
>
> Rather worrying there were that many.

Isn't that the point of this release, fix issues :)

Yes, I use tcsh for interactive use, ksh for scripting.

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
> Aragorn <thorongil@telenet.be> writes:
>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>> there's a legacy reason not to.

Everyone, here being the small group you think representative.

If you are excluding zsh, you have not met my coworkers.

>> I'm not so sure about tcsh being all that popular. While it makes for
>> a decent interactive shell, it's a bad one for scripting because of its
>> many unpredictable/undefined behaviors.

I gather most tcsh usage is interactive, not scripted.

> I think mutt would be surprised at the extent to which
> ksh is still used.

Panix sells access to shared unix shell accounts, and has since the
early 1990s. Originally it was A/UX, then SunOS, now NetBSD shell hosts.
I've been a customer since 1997.

:r! cut -f 7 -d : /etc/passwd | sort | uniq -c | sort -nr | head
533 /usr/local/bin/bash
422 /usr/local/bin/tcsh
414 /usr/local/bin/psh
180 /usr/local/bin/zsh
91 /usr/local/bin/ksh
27 /bin/false
15 /usr/local/bin/ksh93
14 /bin/sh
9 /bin/ksh
8 /bin/csh

In these results, ksh and ksh93 are different versions (but /bin/ksh is
the same as /usr/local/bin/ksh). And psh is a homegrown menu driven
shell. I've checked, and all /bin/sh accounts but "Charlie &" are
regular human accounts.

I am one of the ksh93 users ("Version AJM 93u+ 2012-08-01"), while ksh
is PD ksh ("PD KSH v5.2.14 99/07/13.2"), likely the ksh that ships with
this version of NetBSD.

However many bugs there are in this ksh, there are only three that
regularly bite me, and yet I'm still interested in this new ksh release.

Elijah
------
has shell preferences, but can use whatever, including busybox sh

Op 02-08-22 om 20:06 schreef muttley@dastardlyhq.com:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>> It may have been exactly a decade since the last one, but here it is at
>> last: a proper new ksh release. :) Many thanks to all contributors for
>
> The ship sailed long ago, arrived at its destination, did a round the
> world tour and was scrapped. Everyone uses bash or tcsh now unless there's
> a legacy reason not to.

Thank you for your helpful input. I will abandon this project
immediately and disappoint the co-developers and die-hard ksh users.
This will allow me to spend my free time on more productive pursuits
such as playing sudoku or watching football.

>> Roughly a thousand bugs have been fixed, including many serious/critical
>
> Rather worrying there were that many.

Quite. It was a mess.

That some users stuck with it anyway means something, though.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

[German-language group removed]

Op 03-08-22 om 02:14 schreef Eli the Bearded:
> Panix sells access to shared unix shell accounts, and has since the
> early 1990s. Originally it was A/UX, then SunOS, now NetBSD shell hosts.
> I've been a customer since 1997.
>
> :r! cut -f 7 -d : /etc/passwd | sort | uniq -c | sort -nr | head
> 533 /usr/local/bin/bash
> 422 /usr/local/bin/tcsh
> 414 /usr/local/bin/psh
> 180 /usr/local/bin/zsh
> 91 /usr/local/bin/ksh
> 27 /bin/false
> 15 /usr/local/bin/ksh93
[...]
> I am one of the ksh93 users ("Version AJM 93u+ 2012-08-01"), while ksh
> is PD ksh ("PD KSH v5.2.14 99/07/13.2"), likely the ksh that ships with
> this version of NetBSD.

Certainly those statistics don't look all that good for interactive use
of ksh93. But I think the interest in ksh93 as a scripting language has
generally been stronger than the interest in using it as an interactive
shell. There are a lot of legacy ksh93 scripts still in use and there
are still some people writing new scripts.

> However many bugs there are in this ksh, there are only three that
> regularly bite me, and yet I'm still interested in this new ksh release.

Out of interest, what are those three bugs? Hopefully they're fixed in
93u+m, but if not, I'd certainly like to know.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

Op 02-08-22 om 20:30 schreef Auric__:
> Maybe some people prefer ksh? I mean, I bet the devs do, at the very least.

Oddly enough, I wasn't even really a ksh user as such. I sort of like
all shells equally. I was writing a cross-platform shell scripting
library, modernish, which caused me to find all sorts of bugs in a lot
of different shells, and a *lot* of bugs in ksh93.

Those other shell bugs could be fixed by reporting them to their
authors, but ksh93 was abandoned, and attempts to revive it were all
failing or stalling. But there were a lot of third-party patches to
integrate[*], and I found that I knew how to fix some other bugs myself,
so I forked the repo and went for it. Before I knew it, two others
joined me and there was a loosely knit team.

Of course you've got to eat your own dog food, so now I use ksh all the
time, interactively and for scripting. When something annoys me I try to
fix it, so I've been turning it into something I would want to use.

[*] https://github.com/ksh93/ksh/wiki#upstreamed-third-party-ksh-93u-patches

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

muttley@dastardlyhq.com crossposted to
comp.unix.shell,de.comp.os.unix.shell,comp.unix.programmer, ignoring
Martijn Dekker's Followup-To: comp.unix.shell header field:

[…]

Please, don't keep crossposting to the german speaking newsgroup
de.comp.os.unix.shell unless you are willing to post in German.

Martijn suggested to discuss the shell in comp.unix.shell, which is
the perfect place to do, that's why he put a Followup-To header
field in his article.

So, unless you've got a very good reason to ignore it, you should
obey him.

Thank you in advance.

Crosspost & Followup-To: comp.unix.shell

muttley@dastardlyhq.com crossposted to
comp.unix.shell,de.comp.os.unix.shell,comp.unix.programmer, ignoring
Martijn Dekker's Followup-To: comp.unix.shell header field:

[…]

Please, don't keep crossposting to the german speaking newsgroup
de.comp.os.unix.shell unless you are willing to post in German.

Martijn suggested to discuss the shell in comp.unix.shell, which is
the perfect place to do, that's why he put a Followup-To header
field in his article.

So, unless you've got a very good reason to ignore it, you should
obey him.

Thank you in advance.

Crosspost & Followup-To: comp.unix.shell

On Tue, 2 Aug 2022 23:05:58 -0000 (UTC)
John McCue <jmccue@neutron.hsd1.ma.comcast.net> wrote:
>Follow-ups trimmed to comp.unix.shell
>
>In comp.unix.shell muttley@dastardlyhq.com wrote:
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>>>It may have been exactly a decade since the last one, but here it is at
>>>last: a proper new ksh release. :) Many thanks to all contributors for
>>
>> The ship sailed long ago, arrived at its destination, did a round the
>> world tour and was scrapped.
>
>I miss the meaning of this.

Going my your name I'm assuming you're a native english speaker but you've
never heard the expression "That ship has sailed"?

>
>> Everyone uses bash or tcsh now unless there's
>> a legacy reason not to.
>
>No, maybe everyone on Linux, but there are other UNIX
>systems and ksh is used on them. ksh is the default
>shell for AIX.

Is AIX still used much outside of legacy systems?

>>>many serious/critical
>>
>> Rather worrying there were that many.
>
>Isn't that the point of this release, fix issues :)

I don't know if the people involved in this latest update were responsible
for the previous version. If they are then its worrying there were serious
and critical errors in the shell for 10 years that black hats could have
exploited.

On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:
>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>> Aragorn <thorongil@telenet.be> writes:
>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>> there's a legacy reason not to.
>
>Everyone, here being the small group you think representative.

The last 4 companies I've worked at all used Linux and bash was the shell.
One of these companies was a major aircraft manufacturer.

>If you are excluding zsh, you have not met my coworkers.

I probably should have included zsh because of MacOS. tsch is used on FreeBSD.

>However many bugs there are in this ksh, there are only three that
>regularly bite me, and yet I'm still interested in this new ksh release.

I can't even remember the last time I had an issue with a bug in bash.

On Wed, 03 Aug 2022 07:47:31 +0200
Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>muttley@dastardlyhq.com crossposted to
>comp.unix.shell,de.comp.os.unix.shell,comp.unix.programmer, ignoring
>Martijn Dekker's Followup-To: comp.unix.shell header field:
>
>[=E2=80=A6]
>
>Please, don't keep crossposting to the german speaking newsgroup
>de.comp.os.unix.shell unless you are willing to post in German.
>
>Martijn suggested to discuss the shell in comp.unix.shell, which is
>the perfect place to do, that's why he put a Followup-To header
>field in his article.
>
>So, unless you've got a very good reason to ignore it, you should
>obey him.

My very good reason is I don't subscribe to comp.os.unix.shell. Followups
are rude and I have them disabled in my newsreader. If you only want to post
in 1 group then only post in 1 group. Don't post in 3 so people replying
in non followup groups never see either their message or any other responses.

>Crosspost & Followup-To: comp.unix.shell

Ignored.

muttley@dastardlyhq.com writes:
>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>Eli the Bearded <*@eli.users.panix.com> wrote:
>>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>> Aragorn <thorongil@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>> there's a legacy reason not to.
>>
>>Everyone, here being the small group you think representative.
>
>The last 4 companies I've worked at all used Linux and bash was the shell.
>One of these companies was a major aircraft manufacturer.

Many distributions of linux installed ksh alongside bash. Did
you check the nis maps for a pop count on each shell?

tcsh is widely used on linux, in my company it is by far the most
used shell.

$ ypcat passwd | grep tcsh | wc -l
1941
$ ypcat passwd | grep bash | wc -l
352
$ ypcat passwd | grep ksh | wc -l
44

On 04/08/2022 05:00, muttley@dastardlyhq.com wrote:
> On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>> Aragorn <thorongil@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>> there's a legacy reason not to.
>>
>> Everyone, here being the small group you think representative.
>
> The last 4 companies I've worked at all used Linux and bash was the shell.
> One of these companies was a major aircraft manufacturer.
>
>> If you are excluding zsh, you have not met my coworkers.
>
> I probably should have included zsh because of MacOS. tsch is used on FreeBSD.
>
zsh is big in Japan, not just on Linux boxes but on Solaris systems as
well. (Yes, Solaris is still big in the corporate data centres of the
rising sun.)

Cheers,
Gary B-)

muttley@dastardlyhq.com:
>On Wed, 03 Aug 2022 07:47:31 +0200
>Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>>muttley@dastardlyhq.com crossposted to
>>comp.unix.shell,de.comp.os.unix.shell,comp.unix.programmer, ignoring
>>Martijn Dekker's Followup-To: comp.unix.shell header field:

>>Please, don't keep crossposting to the german speaking newsgroup
>>de.comp.os.unix.shell unless you are willing to post in German.
>>
>>Martijn suggested to discuss the shell in comp.unix.shell, which is
>>the perfect place to do, that's why he put a Followup-To header
>>field in his article.
>>
>>So, unless you've got a very good reason to ignore it, you should
>>obey him.
>
>My very good reason is I don't subscribe to comp.os.unix.shell.
>

Imagine:  Nobody subscribes to “comp.os.unix.shell”!  And that's the
reason why you prefer to dump your English text into the German
speaking newsgroup “de.comp.os.unix.shell”?  You'd better shut up in
a discussion which is ontopic only in the newsgroup
“comp.unix.shell” unless you are willing to discuss it there. 
Nobody will buy you having subcribed to “de.comp.os.unix.shell”.  So
at least you should have removed “de.comp.os.unix.shell” from the
“Newsgroups” header field!

>Followups are rude and I have them disabled in my newsreader. If
>you only want to post in 1 group then only post in 1 group.

That's nonsense!  Martijns post is an English announcement of a new
version of the “ksh” shell.  A short English announcement is fine
even in a German speaking newsgroup, where “ksh” users read, whereas
a discussion in the English language by people like you, who won't
bother writing their posts both in English and German to get them
ontopic in the German‐speaking newsgroup, is not.

Apart from that, discussing “ksh” is offtopic even in
“comp.unix.programmer” (unless you are going to improve its code and
need help in programming for unix).  The only appropriate newsgroup
is “comp.unix.shell”.  So it's debatable, whether Martijn shouldn't
have posted his announcement to “comp.unix.shell”.

>Don't post in 3 so people replying in non followup groups never see
>either their message or any other responses.

That's why one inserts a note in the body of the message, announcing
the “Followup-To” header field, like here:

>
>>Crosspost & Followup-To: comp.unix.shell
>>

Then everybody may consider subscribing to the newsgroup.

>Ignored.
>

And now, piss off!  As long as you won't write in German,
“de.comp.os.unix.shell” is the wrong place for your posts.

Helmut Waitzmann <nn.throttle@xoxy.net>:

>Apart from that, discussing “ksh” is offtopic even in
>“comp.unix.programmer” (unless you are going to improve its code
>and need help in programming for unix).  The only appropriate
>newsgroup is “comp.unix.shell”.  So it's debatable, whether Martijn
>shouldn't have posted his announcement to “comp.unix.shell”.

The last sentence is wrong.  It rather should have read as follows:

So it's debatable, whether Martijn shouldn't have posted his
announcement to “comp.unix.programmer”.

On Wed, 03 Aug 2022 19:45:05 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>muttley@dastardlyhq.com writes:
>>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>>Eli the Bearded <*@eli.users.panix.com> wrote:
>>>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>>> Aragorn <thorongil@telenet.be> writes:
>>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>>> there's a legacy reason not to.
>>>
>>>Everyone, here being the small group you think representative.
>>
>>The last 4 companies I've worked at all used Linux and bash was the shell.
>>One of these companies was a major aircraft manufacturer.
>
>Many distributions of linux installed ksh alongside bash. Did
>you check the nis maps for a pop count on each shell?

No, but ksh wasn't supported at any of them so if someone used it they'd
have to accept possible incompatabilities with company build and admin
scripts.

muttley@dastardlyhq.com writes:
>On Wed, 03 Aug 2022 19:45:05 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>muttley@dastardlyhq.com writes:
>>>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>>>Eli the Bearded <*@eli.users.panix.com> wrote:
>>>>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>>>> Aragorn <thorongil@telenet.be> writes:
>>>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>>>> there's a legacy reason not to.
>>>>
>>>>Everyone, here being the small group you think representative.
>>>
>>>The last 4 companies I've worked at all used Linux and bash was the shell.
>>>One of these companies was a major aircraft manufacturer.
>>
>>Many distributions of linux installed ksh alongside bash. Did
>>you check the nis maps for a pop count on each shell?
>
>No, but ksh wasn't supported at any of them so if someone used it they'd
>have to accept possible incompatabilities with company build and admin
>scripts.
>

Why is that? The scripts should all have hash-bang introductions
which specify exactly which shell the script uses. (e.g. #!/bin/ksh).

The users interactive shell is completly orthoganal to any shell
scripts executed from that shell which execute under the appropriate
shell.

On Thu, 04 Aug 2022 19:29:44 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>muttley@dastardlyhq.com writes:
>>On Wed, 03 Aug 2022 19:45:05 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>muttley@dastardlyhq.com writes:
>>>>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>>>>Eli the Bearded <*@eli.users.panix.com> wrote:
>>>>>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>>>>> Aragorn <thorongil@telenet.be> writes:
>>>>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>>>>> there's a legacy reason not to.
>>>>>
>>>>>Everyone, here being the small group you think representative.
>>>>
>>>>The last 4 companies I've worked at all used Linux and bash was the shell.
>>>>One of these companies was a major aircraft manufacturer.
>>>
>>>Many distributions of linux installed ksh alongside bash. Did
>>>you check the nis maps for a pop count on each shell?
>>
>>No, but ksh wasn't supported at any of them so if someone used it they'd
>>have to accept possible incompatabilities with company build and admin
>>scripts.
>>
>
>Why is that? The scripts should all have hash-bang introductions
>which specify exactly which shell the script uses. (e.g. #!/bin/ksh).

Should. How often do you see it in practice?

muttley@dastardlyhq.com writes:
>On Thu, 04 Aug 2022 19:29:44 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>muttley@dastardlyhq.com writes:
>>>On Wed, 03 Aug 2022 19:45:05 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>muttley@dastardlyhq.com writes:
>>>>>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>>>>>Eli the Bearded <*@eli.users.panix.com> wrote:
>>>>>>In comp.unix.shell, Scott Lurndal <slp53@pacbell.net> wrote:
>>>>>>> Aragorn <thorongil@telenet.be> writes:
>>>>>>>> On 02.08.2022 at 18:06, muttley@dastardlyhq.com scribbled:
>>>>>>>>> world tour and was scrapped. Everyone uses bash or tcsh now unless
>>>>>>>>> there's a legacy reason not to.
>>>>>>
>>>>>>Everyone, here being the small group you think representative.
>>>>>
>>>>>The last 4 companies I've worked at all used Linux and bash was the shell.
>>>>>One of these companies was a major aircraft manufacturer.
>>>>
>>>>Many distributions of linux installed ksh alongside bash. Did
>>>>you check the nis maps for a pop count on each shell?
>>>
>>>No, but ksh wasn't supported at any of them so if someone used it they'd
>>>have to accept possible incompatabilities with company build and admin
>>>scripts.
>>>
>>
>>Why is that? The scripts should all have hash-bang introductions
>>which specify exactly which shell the script uses. (e.g. #!/bin/ksh).
>
>Should. How often do you see it in practice?
>

100%. As noted in other posts, we use a number of different interactive
shells, and a number of scripting languages (tcsh, ksh, bash, perl, python,
tcl, et alia). And that's been true for every POE I've worked in for
the last three plus decades (system or processor OEMs primarily).

If there's no she-bang, then the script can still be run by
explicitly invoking the appropriate shell (bash /path/to/bash/script).

On Thu, 04 Aug 2022 20:28:06 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>muttley@dastardlyhq.com writes:
>>Should. How often do you see it in practice?
>>
>
>100%. As noted in other posts, we use a number of different interactive
>shells, and a number of scripting languages (tcsh, ksh, bash, perl, python,
>tcl, et alia). And that's been true for every POE I've worked in for
>the last three plus decades (system or processor OEMs primarily).

Don't believe you. I've seen more scripts than I can count that didn't
have the hash bang at the start. No idea what a she-bang is. Sounds like
a service for sailors in a port.

>
>If there's no she-bang, then the script can still be run by
>explicitly invoking the appropriate shell (bash /path/to/bash/script).

It'll be invoked directly anyway by /bin/sh if its +x. I'd have thought in
you three plus decades of experience would have discovered that by now.

muttley@dastardlyhq.com writes:

> On Thu, 04 Aug 2022 20:28:06 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>muttley@dastardlyhq.com writes:
>>>Should. How often do you see it in practice?
>>>
>>
>>100%. As noted in other posts, we use a number of different interactive
>>shells, and a number of scripting languages (tcsh, ksh, bash, perl, python,
>>tcl, et alia). And that's been true for every POE I've worked in for
>>the last three plus decades (system or processor OEMs primarily).
>
> Don't believe you. I've seen more scripts than I can count that didn't
> have the hash bang at the start. No idea what a she-bang is. Sounds like
> a service for sailors in a port.

Well, where I worked, every shell script we shipped to customers had
a hash bang. Feel free to not believe me too.

--
Dan Espen