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

On 01.08.2022 22:40, Martijn Dekker wrote:
> Announcing: KornShell 93u+m/1.0.0

Thanks a lot!

(Hadn't yet the time to install/test/use it, but appreciate the effort
and will certainly use it given the experience I made with the release
you provided quite some time ago.)

>
> Or ask your distribution package manager to upgrade ksh93 to this version.

I'd appreciate if that would happen to replace "ksh" re-implementations
and the [older buggy] AT&T versions. - Maybe "93m+u" will replace the
original ksh (and the inferior clones) in a similar way as GNU Awk
effectively "replaced" UNIX (and other) Awk, i.e. to become the quasi-
standard for ksh. I'm keen to see how the commercial Unix vendors will
behave in that respect.

Janis

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

Op 02-08-22 om 20:53 schreef Janis Papanagnou:
> On 01.08.2022 22:40, Martijn Dekker wrote:
>> Announcing: KornShell 93u+m/1.0.0
>
> Thanks a lot!
>
> (Hadn't yet the time to install/test/use it, but appreciate the effort
> and will certainly use it given the experience I made with the release
> you provided quite some time ago.)

Neat. Lots more has been fixed since then and a few things added, e.g.,
'set -b' notifications no longer mess up your command line display.
Please let me know of any problems you find.

>> Or ask your distribution package manager to upgrade ksh93 to this version.
>
> I'd appreciate if that would happen to replace "ksh" re-implementations
> and the [older buggy] AT&T versions. - Maybe "93m+u" will replace the
> original ksh (and the inferior clones) in a similar way as GNU Awk
> effectively "replaced" UNIX (and other) Awk, i.e. to become the quasi-
> standard for ksh. I'm keen to see how the commercial Unix vendors will
> behave in that respect.

The main ksh clone now is mksh. I would not it inferior. It's the fixed
version of pdksh and Thorsten fixed it properly. It developed in a
different direction, has a grammatically incorrect (yet OSI-certified)
licence, and it's not nearly as featureful, but it's solid.

Solaris uses AT&T ksh93 as their /bin/sh and they seem to want to use
93u+m, or at least they did some time ago. It took time to get it
anywhere close to my release quality standards, and now their team seems
to have changed, so we'll see.

But Debian, Red Hat and Slackware have already made it their default
ksh93 before there even was a release, so there's that. :)

--
|| 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 03.08.2022 06:18, Martijn Dekker wrote:
>
> The main ksh clone now is mksh. I would not [call] it inferior.
> It's the fixed version of pdksh and Thorsten fixed it properly. [...]

I have to admit that some time passed since I last looked at pdksh.
But there had been fundamental functional differences (e.g. pipe
foreground/background processes) and it didn't have the features
I was used from AT&T ksh. The "inferior" was not meant to value
the software quality but those observable functional differences.
I haven't examined the differences between pdksh and mksh.

[...]
> But Debian, Red Hat and Slackware have already made it their default
> ksh93 before there even was a release, so there's that. :)

:-)

Janis

On 03.08.2022 01:05, John McCue wrote:
> Follow-ups trimmed to comp.unix.shell
> In comp.unix.shell muttley@dastardlyhq.com wrote:
>
>> Everyone uses bash or tcsh now unless there's
>> a legacy reason not to.
>
> No, maybe everyone on Linux,

It's not even true for "everyone on Linux".

Janis

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.

Trimmed to comp.unix.shell

In comp.unix.shell muttley@dastardlyhq.com wrote:
<snip>
>>>
>>> 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"?

Yes, I have heard that phase, but my confusion comes in
with the point/reason for the sentence. A group of people
are updating a shell used by a lot of commercial UNIX
systems, which I think is great.

Having this shell allows people on Linux/BSD to test
scripts using the real ksh without having to log into
that system at work. Avoiding hassles with VPNs, corporate
requirements and dated editing tools.

<snip>

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

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

Dropped from newsgroups: de.comp.os.unix.shell,comp.unix.programmer

In comp.unix.shell, <muttley@dastardlyhq.com> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> 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.

I use bash when ksh is not installed, but it works differently and I
notice. I use /bin/sh when I need to, but it works differently and I
notice. No one is arguing that bash isn't used, just that it's not as
ubiquious as you claim.

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

Note that I provided numbers for usage on NetBSD.

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

Since I use it more sparingly, and mostly under "fix some problem on a
random host", I likely have fewer opportunities to find bash bugs. I
find differences often. I will note this is a "ten year" collection of
bugs being fixed, and shellshock was less than ten years ago.

Differences in bash that bug me:

It's a _huge_ misfeature to me that lines beginning with a space are
excluded from history by default. (Most of the time I use bash, it's a
server I have just logged into for the first time. I need to type my
shell preferences out to have them.)

It's my opinionated feeling that in "set - o vi" mode, bash handles
multiline things in history wrong.

Bash 4 (?) introduced PS0 and broke old .profile settings for me.

I'm sure at least some regular bash users have encountered actual bugs
that I've missed.

Elijah
------
believes the ksh issues he knew about are fixed in this release

Eli the Bearded <*@eli.users.panix.com> writes:
[...]
> It's a _huge_ misfeature to me that lines beginning with a space are
> excluded from history by default. (Most of the time I use bash, it's a
> server I have just logged into for the first time. I need to type my
> shell preferences out to have them.)
[...]

I'm not a big fan of that feature myself, but I can see the point of it.
There might be times when you want to execute a command and not have it
saved in history. For example, on rare occasions you might need to
include a password in a command. Typing the command with a leading
space is an easy way to do that.

`unset HISTCONTROL` will turn it off, along the feature that prevents
duplicate commands from being saved in history.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

On 03.08.2022 at 21:22, Eli the Bearded scribbled:

> It's a _huge_ misfeature to me that lines beginning with a space are
> excluded from history by default. (Most of the time I use bash, it's a
> server I have just logged into for the first time. I need to type my
> shell preferences out to have them.)

This is site-specific. Arch and derivative GNU/Linux distributions —
I'm running Manjaro [*] here — don't exclude entries that start with a
space from the shell's history by default, although I personally like
that functionality and have added it to my .bashrc — or possibly to my
..bash_profile; it's been a long time so I'd have to check.

There are yet other GNU/Linux distributions that don't exclude
command-line entries starting with a space from the history; PCLinuxOS
springs to mind, although its main upstream — OpenMandriva — does, and
possibly Fedora as well.

[*] As of late last year or so, Manjaro now uses zsh as the interactive
shell in the GUI terminal emulators of all three official Manjaro
editions — i.e. the Plasma edition, the GNOME edition and the XFCE
edition — because the newbies like the esthetics of the
Powerline-10K-themed prompt, but it still uses bash as the main
shell for the system itself and for tty and ssh logins.

My installation on this machine dates back to long before the switch
to zsh and I've stuck with bash because it's the shell of my
preference. zsh looks nice visually, but it's way too different
and it's not a POSIX shell, which means that its behavior is too
unpredictable for my taste without first studying the ins and outs
of it, for which I don't have the time anymore.

--
With respect,
= Aragorn