info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[ANN] KornShell 93u+m/1.0.0
0 views
Skip to first unread message
Martijn Dekker
Aug 1, 2022, 4:40:41 PM8/1/22
to
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 mar...@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.
- A new --nobackslashctrl shell option disables the special escaping
behaviour of the backslash character in the emacs and vi built-in
editors.
Particularly in the emacs editor, this makes it much easier to go back,
insert a forgotten backslash into a command, and then continue editing
without having your next arrow key replace your backslash with garbage.
- A new --posix shell option has been added to ksh 93u+m that makes the
ksh language more compatible with other shells by following the POSIX
standard more closely. See the manual page for details. It is enabled by
default if ksh is invoked as sh, otherwise it is disabled by default.
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
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 mar...@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.
- A new --nobackslashctrl shell option disables the special escaping
behaviour of the backslash character in the emacs and vi built-in
editors.
Particularly in the emacs editor, this makes it much easier to go back,
insert a forgotten backslash into a command, and then continue editing
without having your next arrow key replace your backslash with garbage.
- A new --posix shell option has been added to ksh 93u+m that makes the
ksh language more compatible with other shells by following the POSIX
standard more closely. See the manual page for details. It is enabled by
default if ksh is invoked as sh, otherwise it is disabled by default.
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
mut...@dastardlyhq.com
Aug 2, 2022, 2:06:10 PM8/2/22
to
On Mon, 1 Aug 2022 22:40:39 +0200
Martijn Dekker <mar...@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
Martijn Dekker <mar...@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
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
Auric__
Aug 2, 2022, 2:30:50 PM8/2/22
to
muttley wrote:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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.
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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.
--
What value is a bar of gold to a man dying of thirst in the desert?
Aragorn
Aug 2, 2022, 2:40:02 PM8/2/22
to
On 02.08.2022 at 18:06, mut...@dastardlyhq.com scribbled:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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 Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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.
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 =
Scott Lurndal
Aug 2, 2022, 3:43:01 PM8/2/22
to
Aragorn <thor...@telenet.be> writes:
>On 02.08.2022 at 18:06, mut...@dastardlyhq.com scribbled:
>
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <mar...@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
>On 02.08.2022 at 18:06, mut...@dastardlyhq.com scribbled:
>
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <mar...@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
>>=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
>> 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.
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.
John McCue
Aug 2, 2022, 7:05:59 PM8/2/22
to
Follow-ups trimmed to comp.unix.shell
In comp.unix.shell mut...@dastardlyhq.com wrote:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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 mut...@dastardlyhq.com wrote:
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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.
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.
Yes, I use tcsh for interactive use, ksh for scripting.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
Eli the Bearded
Aug 2, 2022, 8:14:02 PM8/2/22
to
In comp.unix.shell, Scott Lurndal <sl...@pacbell.net> wrote:
> Aragorn <thor...@telenet.be> writes:
>> On 02.08.2022 at 18:06, mut...@dastardlyhq.com scribbled:
> Aragorn <thor...@telenet.be> writes:
>> On 02.08.2022 at 18:06, mut...@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.
>>> there's a legacy reason not to.
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 think mutt would be surprised at the extent to which
> ksh is still used.
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
Martijn Dekker
Aug 2, 2022, 10:06:07 PM8/2/22
to
Op 02-08-22 om 20:06 schreef mut...@dastardlyhq.com:
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.
> On Mon, 1 Aug 2022 22:40:39 +0200
> Martijn Dekker <mar...@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
> Martijn Dekker <mar...@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.
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.
That some users stuck with it anyway means something, though.
Helmut Waitzmann
Aug 3, 2022, 1:56:31 AM8/3/22
to
mut...@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
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
Martijn Dekker
Aug 3, 2022, 4:17:23 AM8/3/22
to
Op 03-08-22 om 07:47 schreef Helmut Waitzmann:
an der/die/das (?) Followup-to halten würden.
Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie vorziehen,
dann passe ich mich darauf an.
Mit freundlige Grüße,
- Martijn (der deutlich nicht echt Deutsch spricht!)
> 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.
Entschuldigung, ich hätte es ankommen sehen müssen dass nicht jeder sich
> the perfect place to do, that's why he put a Followup-To header
> field in his article.
an der/die/das (?) Followup-to halten würden.
Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie vorziehen,
dann passe ich mich darauf an.
Mit freundlige Grüße,
- Martijn (der deutlich nicht echt Deutsch spricht!)
Marco Moock
Aug 3, 2022, 4:31:25 AM8/3/22
to
On Wed, 3 Aug 2022 10:17:20 +0200
Martijn Dekker <mar...@inlv.demon.nl> wrote:
> Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
> dieser Gruppe heraushalte?
Auf Deutsch gerne, aber in anderen Sprachen gibt es andere Gruppen. Die
Martijn Dekker <mar...@inlv.demon.nl> wrote:
> Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
> dieser Gruppe heraushalte?
meisten Leute lesen auch die englischen Gruppen zu Linux, wenn sie die
deutschen lesen.
--
Gruß
Marco
Ralph Angenendt
Aug 3, 2022, 4:43:18 AM8/3/22
to
Well, Martijn Dekker <mar...@inlv.demon.nl> wrote:
> Op 03-08-22 om 07:47 schreef Helmut Waitzmann:
>> 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.
>
> Entschuldigung, ich hätte es ankommen sehen müssen dass nicht jeder sich
> an der/die/das (?) Followup-to halten würden.
>
> Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
> dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie vorziehen,
> dann passe ich mich darauf an.
Das Announcment ist natürlich willkommen hier, eventuell sollte es einen
> Op 03-08-22 om 07:47 schreef Helmut Waitzmann:
>> 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.
>
> Entschuldigung, ich hätte es ankommen sehen müssen dass nicht jeder sich
> an der/die/das (?) Followup-to halten würden.
>
> Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz aus
> dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie vorziehen,
> dann passe ich mich darauf an.
etwas eindeutigeren Hinweis darauf geben, dass Leute sich an das
"Followup-To" halten sollten (oder einen deutlichen Hinweis darauf, dass
die Diskussion in der englischsprachigen Gruppe stattfinden sollte).
I believe the announcement is more than welcome here, even though it's
not a german language posting. Maybe there should be a more prominent
pointer to the Followup-To in the post though, or evem a request that
people should stick to the english speaking group, if they see a need to
discuss the announcement.
This won't work either, but in that case you did what you could do :)
Das funktioniert zwar auch nicht, aber mehr geht von deiner Seite
halt nicht :)
Dank je wel
Ralph
--
Is your mother worried?
Would you like us to assign someone to worry your mother?
Helmut Waitzmann
Aug 3, 2022, 10:54:32 AM8/3/22
to
Martijn Dekker <mar...@inlv.demon.nl>:
üblich.) Also: Du hättest das nicht kommen sehen müssen. Du bist
für die mangelnde Kinderstube anderer nicht verantwortlich. Du hast
das «Followup-To»‐Vorspannfeld genau so eingesetzt, wie es gedacht
ist.
Vielleicht wäre bei dem «Followup-To»‐Missachter der Groschen
gefallen, wenn dein Announcement sowohl einen englisch‐ als auch
einen deutschsprachigen Teil gehabt hätte. Aber viel Hoffnung habe
ich dabei nicht.
>Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz
>aus dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie
>vorziehen, dann passe ich mich darauf an.
Eine Ankündigung einer neuen «ksh»‐Fassung ist kein Problem, im
Gegenteil, durchaus gewünscht. Schließlich gibt es auch
deutschsprachige Usenetizen, die «comp.unix.shell» nicht lesen, weil
sie nicht auf Englisch diskutieren können, aber mit einer
englischsprachigen Ankündigung einer neuen Fassung trotdem noch
etwas anfangen können.
Nur die Diskussion – sofern eine stattfindet – sollte dann in der
der Gruppe entsprechenden Sprache stattfinden. Wer sie dann
beispielsweise auf Englisch verfolgen oder sich beteiligen will,
kann das ja dann in «comp.unix.shell» tun. Wer eine auf Deutsch
anzetteln will, kann seine Antwort auf Deutsch verfassen, dein
«Followup-To»‐Vorspannfeld ignorieren und statt dessen eines für
«de.comp.os.unix.shell» mitliefern.
Es gibt Leser im deutschsprachigen Usenet, die mit Englisch nicht
viel anfangen können. Da ist es mir wirklich wichtig, dass die
nicht den Eindruck erhalten, ausgeschlossen zu sein, nur, weil sie
Englisch nicht gut beherrschen.
Dazu kannst du aber nicht mehr beitragen, als ein
«Followup-To»‐Vorspannfeld zu benutzen und im Text extra noch um
freundliche Beachtung zu bitten. Und das hast du ja getan.
Das ist ja im Usenet auch bewährte Praxis: Man schaue sich nur mal
die Beiträge in den verschiedenen «*.answers»‐Newsgroups an. Sie
tragen alle ein «Followup-To»‐Vorspannfeld in die ihrer Sprache
entsprechende Hierarchie.
Wenn ich das recht verfolgt habe, war es ja nur eine einzige Person,
die dein «Followup-To»‐Vorspannfeld ignoriert (und allerdings eine
lebhafte Diskussion losgetreten) hat.
Ich vermute, sie hat das absichtlich getan, denn vernünftige
Newsreader schlagen vor, dem «Followup-To»‐Vorspannfeld zu folgen,
d. h., man kann das eigentlich nicht versehentlich ignorieren.
Darum habe ich meinen Hinweis als Followup auf diese eine
Person gemacht. Es darf sich also in erster Linie genau die Person
den Schuh anziehen, an deren Beitrag mein Followup anschließt.
>Op 03-08-22 om 07:47 schreef Helmut Waitzmann:
>> 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.
>
>Entschuldigung, ich hätte es ankommen sehen müssen dass nicht jeder
>sich an der/die/das (?) Followup-to halten würden.
(Darf ich «du» sagen? Das ist im deutschsprachigen Usenet so
>> 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.
>
>Entschuldigung, ich hätte es ankommen sehen müssen dass nicht jeder
>sich an der/die/das (?) Followup-to halten würden.
üblich.) Also: Du hättest das nicht kommen sehen müssen. Du bist
für die mangelnde Kinderstube anderer nicht verantwortlich. Du hast
das «Followup-To»‐Vorspannfeld genau so eingesetzt, wie es gedacht
ist.
Vielleicht wäre bei dem «Followup-To»‐Missachter der Groschen
gefallen, wenn dein Announcement sowohl einen englisch‐ als auch
einen deutschsprachigen Teil gehabt hätte. Aber viel Hoffnung habe
ich dabei nicht.
>Möchten Sie lieber dass ich zukünftige Freigabeankündigungen ganz
>aus dieser Gruppe heraushalte? Lassen Sie mich wissen was Sie
>vorziehen, dann passe ich mich darauf an.
Gegenteil, durchaus gewünscht. Schließlich gibt es auch
deutschsprachige Usenetizen, die «comp.unix.shell» nicht lesen, weil
sie nicht auf Englisch diskutieren können, aber mit einer
englischsprachigen Ankündigung einer neuen Fassung trotdem noch
etwas anfangen können.
Nur die Diskussion – sofern eine stattfindet – sollte dann in der
der Gruppe entsprechenden Sprache stattfinden. Wer sie dann
beispielsweise auf Englisch verfolgen oder sich beteiligen will,
kann das ja dann in «comp.unix.shell» tun. Wer eine auf Deutsch
anzetteln will, kann seine Antwort auf Deutsch verfassen, dein
«Followup-To»‐Vorspannfeld ignorieren und statt dessen eines für
«de.comp.os.unix.shell» mitliefern.
Es gibt Leser im deutschsprachigen Usenet, die mit Englisch nicht
viel anfangen können. Da ist es mir wirklich wichtig, dass die
nicht den Eindruck erhalten, ausgeschlossen zu sein, nur, weil sie
Englisch nicht gut beherrschen.
Dazu kannst du aber nicht mehr beitragen, als ein
«Followup-To»‐Vorspannfeld zu benutzen und im Text extra noch um
freundliche Beachtung zu bitten. Und das hast du ja getan.
Das ist ja im Usenet auch bewährte Praxis: Man schaue sich nur mal
die Beiträge in den verschiedenen «*.answers»‐Newsgroups an. Sie
tragen alle ein «Followup-To»‐Vorspannfeld in die ihrer Sprache
entsprechende Hierarchie.
Wenn ich das recht verfolgt habe, war es ja nur eine einzige Person,
die dein «Followup-To»‐Vorspannfeld ignoriert (und allerdings eine
lebhafte Diskussion losgetreten) hat.
Ich vermute, sie hat das absichtlich getan, denn vernünftige
Newsreader schlagen vor, dem «Followup-To»‐Vorspannfeld zu folgen,
d. h., man kann das eigentlich nicht versehentlich ignorieren.
Darum habe ich meinen Hinweis als Followup auf diese eine
Person gemacht. Es darf sich also in erster Linie genau die Person
den Schuh anziehen, an deren Beitrag mein Followup anschließt.
mut...@dastardlyhq.com
Aug 3, 2022, 2:56:28 PM8/3/22
to
On Tue, 2 Aug 2022 23:05:58 -0000 (UTC)
John McCue <jmc...@neutron.hsd1.ma.comcast.net> wrote:
>Follow-ups trimmed to comp.unix.shell
>
>In comp.unix.shell mut...@dastardlyhq.com wrote:
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <mar...@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
John McCue <jmc...@neutron.hsd1.ma.comcast.net> wrote:
>Follow-ups trimmed to comp.unix.shell
>
>In comp.unix.shell mut...@dastardlyhq.com wrote:
>> On Mon, 1 Aug 2022 22:40:39 +0200
>> Martijn Dekker <mar...@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.
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.
>>>many serious/critical
>>
>> Rather worrying there were that many.
>
>Isn't that the point of this release, fix issues :)
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.
mut...@dastardlyhq.com
Aug 3, 2022, 3:00:02 PM8/3/22
to
On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:
>In comp.unix.shell, Scott Lurndal <sl...@pacbell.net> wrote:
>> Aragorn <thor...@telenet.be> writes:
>>> On 02.08.2022 at 18:06, mut...@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.
Eli the Bearded <*@eli.users.panix.com> wrote:
>In comp.unix.shell, Scott Lurndal <sl...@pacbell.net> wrote:
>> Aragorn <thor...@telenet.be> writes:
>>> On 02.08.2022 at 18:06, mut...@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.
One of these companies was a major aircraft manufacturer.
>If you are excluding zsh, you have not met my coworkers.
>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.
mut...@dastardlyhq.com
Aug 3, 2022, 3:06:35 PM8/3/22
to
On Wed, 03 Aug 2022 07:47:31 +0200
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>mut...@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]
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>mut...@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. Followups
>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.
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.
Scott Lurndal
Aug 3, 2022, 3:45:06 PM8/3/22
to
mut...@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 <sl...@pacbell.net> wrote:
>>> Aragorn <thor...@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, mut...@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
>On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
>Eli the Bearded <*@eli.users.panix.com> wrote:
>>In comp.unix.shell, Scott Lurndal <sl...@pacbell.net> wrote:
>>> Aragorn <thor...@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, mut...@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.
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
Gary R. Schmidt
Aug 3, 2022, 11:09:07 PM8/3/22
to
On 04/08/2022 05:00, mut...@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 <sl...@pacbell.net> wrote:
>>> Aragorn <thor...@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, mut...@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
> On Wed, 3 Aug 2022 00:14:01 -0000 (UTC)
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> In comp.unix.shell, Scott Lurndal <sl...@pacbell.net> wrote:
>>> Aragorn <thor...@telenet.be> writes:
>>>> On 02.08.2022 at 18:06, mut...@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.
>
well. (Yes, Solaris is still big in the corporate data centres of the
rising sun.)
Cheers,
Gary B-)
Helmut Waitzmann
Aug 4, 2022, 10:56:01 AM8/4/22
to
mut...@dastardlyhq.com:
keine Abonnenten! Und deshalb müssen Sie ihren englischen Text in
die deutschsprachige Gruppe «de.comp.os.unix.shell» abkippen? Sie
täten gut daran, in einer Diskussion, die nur in der Gruppe
«comp.unix.shell» ihren Platz hat, zu schweigen, wenn Sie nicht
bereit sind, sie dort zu führen. Niemand nimmt Ihnen ab, dass Sie
die Gruppe «de.comp.os.unix.shell» abonniert haben. Sie hätten also
mindestens «de.comp.os.unix.shell» aus dem «Newsgroups»‐Vorspannfeld
nehmen können!
>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.
Das ist Unsinn! Martijns Beitrag war eine englische Ankündigung
einer neuen «ksh»‐Fassung. Eine kurze englische Ankündigung geht
auch in einer deutschsprachigen Gruppe, in denen «ksh»‐Anwender
mitlesen, in Ordnung, nicht aber eine auf Englisch geführte
Diskussion von Leuten wie Sie, die sich natürlich nicht bequemen,
Ihren Beitrag dann auf Englisch und Deutsch zu verfassen, damit er
in der deutschsprachigen Gruppe seinen Platz hätte.
Im Übrigen hat die Diskussion über den «ksh» selbst in
«comp.unix.programmer» nichts verloren (es sei denn, man will den
Programm‐Code verbessern und braucht Hilfe im Programmieren für
Unix). Die einzige passende Gruppe ist «comp.unix.shell». Man kann
sich daher fragen, ob Martijn seine Ankündigung besser nicht in
«comp.unix.shell» hätte stellen sollen.
>Don't post in 3 so people replying in non followup groups never see
>either their message or any other responses.
Dafür kündigt man ein «Followup-To»‐Vorspannfeld an prominenter
Stelle an, etwa so, wie hier:
>
>>Crosspost & Followup-To: comp.unix.shell
>>
Dann kann sich jeder überlegen, ob er die Gruppe abonniert.
>Ignored.
>
Und jetzt schleichen Sie sich, aber hurtig! Solange Sie nicht
Deutsch schreiben, sind Sie in «de.comp.os.unix.shell» fehl am
Platz!
>On Wed, 03 Aug 2022 07:47:31 +0200
>Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>mut...@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:
>Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>mut...@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.
>
Stellen Sie sich vor: Die Gruppe «comp.os.unix.shell» hat überhaupt
>>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.
>
keine Abonnenten! Und deshalb müssen Sie ihren englischen Text in
die deutschsprachige Gruppe «de.comp.os.unix.shell» abkippen? Sie
täten gut daran, in einer Diskussion, die nur in der Gruppe
«comp.unix.shell» ihren Platz hat, zu schweigen, wenn Sie nicht
bereit sind, sie dort zu führen. Niemand nimmt Ihnen ab, dass Sie
die Gruppe «de.comp.os.unix.shell» abonniert haben. Sie hätten also
mindestens «de.comp.os.unix.shell» aus dem «Newsgroups»‐Vorspannfeld
nehmen können!
>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.
einer neuen «ksh»‐Fassung. Eine kurze englische Ankündigung geht
auch in einer deutschsprachigen Gruppe, in denen «ksh»‐Anwender
mitlesen, in Ordnung, nicht aber eine auf Englisch geführte
Diskussion von Leuten wie Sie, die sich natürlich nicht bequemen,
Ihren Beitrag dann auf Englisch und Deutsch zu verfassen, damit er
in der deutschsprachigen Gruppe seinen Platz hätte.
Im Übrigen hat die Diskussion über den «ksh» selbst in
«comp.unix.programmer» nichts verloren (es sei denn, man will den
Programm‐Code verbessern und braucht Hilfe im Programmieren für
Unix). Die einzige passende Gruppe ist «comp.unix.shell». Man kann
sich daher fragen, ob Martijn seine Ankündigung besser nicht in
«comp.unix.shell» hätte stellen sollen.
>Don't post in 3 so people replying in non followup groups never see
>either their message or any other responses.
Stelle an, etwa so, wie hier:
>
>>Crosspost & Followup-To: comp.unix.shell
>>
Dann kann sich jeder überlegen, ob er die Gruppe abonniert.
>Ignored.
>
Und jetzt schleichen Sie sich, aber hurtig! Solange Sie nicht
Deutsch schreiben, sind Sie in «de.comp.os.unix.shell» fehl am
Platz!
Helmut Waitzmann
Aug 4, 2022, 11:57:19 AM8/4/22
to
Helmut Waitzmann <nn.th...@xoxy.net>:
>Im Übrigen hat die Diskussion über den «ksh» selbst in
>«comp.unix.programmer» nichts verloren (es sei denn, man will den
>Programm‐Code verbessern und braucht Hilfe im Programmieren für
>Unix). Die einzige passende Gruppe ist «comp.unix.shell». Man
>kann sich daher fragen, ob Martijn seine Ankündigung besser nicht
>in «comp.unix.shell» hätte stellen sollen.
Der letzte Satz ist falsch. Richtig hätte er heißen müssen, wie
folgt:
Man kann sich daher fragen, ob Martijn seine Ankündigung besser
nicht in «comp.unix.programmer» hätte stellen sollen.
>Im Übrigen hat die Diskussion über den «ksh» selbst in
>«comp.unix.programmer» nichts verloren (es sei denn, man will den
>Programm‐Code verbessern und braucht Hilfe im Programmieren für
>Unix). Die einzige passende Gruppe ist «comp.unix.shell». Man
>kann sich daher fragen, ob Martijn seine Ankündigung besser nicht
>in «comp.unix.shell» hätte stellen sollen.
folgt:
Man kann sich daher fragen, ob Martijn seine Ankündigung besser
mut...@dastardlyhq.com
Aug 4, 2022, 2:15:35 PM8/4/22
to
On Wed, 03 Aug 2022 19:45:05 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>mut...@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 <sl...@pacbell.net> wrote:
>>>> Aragorn <thor...@telenet.be> writes:
>>>>> On 02.08.2022 at 18:06, mut...@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
sc...@slp53.sl.home (Scott Lurndal) wrote:
>mut...@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 <sl...@pacbell.net> wrote:
>>>> Aragorn <thor...@telenet.be> writes:
>>>>> On 02.08.2022 at 18:06, mut...@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?
have to accept possible incompatabilities with company build and admin
scripts.
Scott Lurndal
Aug 4, 2022, 3:29:46 PM8/4/22
to
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.
mut...@dastardlyhq.com
Aug 4, 2022, 4:10:34 PM8/4/22
to
On Thu, 04 Aug 2022 19:29:44 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>mut...@dastardlyhq.com writes:
>>On Wed, 03 Aug 2022 19:45:05 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>mut...@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 <sl...@pacbell.net> wrote:
>>>>>> Aragorn <thor...@telenet.be> writes:
>>>>>>> On 02.08.2022 at 18:06, mut...@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?
>mut...@dastardlyhq.com writes:
>>On Wed, 03 Aug 2022 19:45:05 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>mut...@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 <sl...@pacbell.net> wrote:
>>>>>> Aragorn <thor...@telenet.be> writes:
>>>>>>> On 02.08.2022 at 18:06, mut...@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).
Scott Lurndal
Aug 4, 2022, 4:28:07 PM8/4/22
to
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).
mut...@dastardlyhq.com
Aug 4, 2022, 4:53:00 PM8/4/22
to
On Thu, 04 Aug 2022 20:28:06 GMT
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.
sc...@slp53.sl.home (Scott Lurndal) wrote:
>mut...@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
>mut...@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).
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).
you three plus decades of experience would have discovered that by now.
Dan Espen
Aug 4, 2022, 5:06:36 PM8/4/22
to
mut...@dastardlyhq.com writes:
> On Thu, 04 Aug 2022 20:28:06 GMT
> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>mut...@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
> On Thu, 04 Aug 2022 20:28:06 GMT
> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>mut...@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.
a hash bang. Feel free to not believe me too.
--
Dan Espen
Scott Lurndal
Aug 4, 2022, 7:23:07 PM8/4/22
to
because it doesn't necessarily invoke /bin/sh, it invokes $SHELL.
And if the shell script being invoked isn't in $SHELL dialect, undefined
behavior will ensue.
That's why we always either use she-bang, or use the invoke the script
using the target shell explicitly.
Mut...@dastardlyhq.com
Aug 6, 2022, 4:34:38 AM8/6/22
to
internal ones as I'm sure you understood.
Mut...@dastardlyhq.com
Aug 6, 2022, 4:36:10 AM8/6/22
to
On Thu, 04 Aug 2022 23:23:05 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>That's why we always either use she-bang, or use the invoke the script
Wtf is "she" for? Its either called hash or pound depending on what side of
sc...@slp53.sl.home (Scott Lurndal) wrote:
>That's why we always either use she-bang, or use the invoke the script
the atlantic you're on. Its never called "she" and I've never heard anyone
anywhere ever refer to it like this.
Janis Papanagnou
Aug 6, 2022, 5:39:46 AM8/6/22
to
Dan Espen
Aug 6, 2022, 8:11:32 AM8/6/22
to
Not really interested in scripts thrown together by a novice.
For what it's worth all my home grown temporary use scripts have a hash
bang too.
--
Dan Espen
Dan Espen
Aug 6, 2022, 8:13:37 AM8/6/22
to
https://en.wikipedia.org/wiki/Shebang_(Unix)
Someone seems to be batting 1000.
--
Dan Espen
Kenny McCormack
Aug 6, 2022, 8:31:07 AM8/6/22
to
In article <tclltg$3r6oa$2...@dont-email.me>,
Dan Espen <dan1...@gmail.com> wrote:
...
--
Atheism:
It's like being the only sober person in the car, and nobody will let you drive.
Dan Espen <dan1...@gmail.com> wrote:
...
>Someone seems to be batting 1000.
Hint: It's not you.
--
Atheism:
It's like being the only sober person in the car, and nobody will let you drive.
Dan Espen
Aug 6, 2022, 9:18:41 AM8/6/22
to
gaz...@shell.xmission.com (Kenny McCormack) writes:
> In article <tclltg$3r6oa$2...@dont-email.me>,
> Dan Espen <dan1...@gmail.com> wrote:
> ...
>>Someone seems to be batting 1000.
>
> Hint: It's not you.
A nonsense comment from Kenny.
> In article <tclltg$3r6oa$2...@dont-email.me>,
> Dan Espen <dan1...@gmail.com> wrote:
> ...
>>Someone seems to be batting 1000.
>
> Hint: It's not you.
Another normal day.
Ask yourself, what is he batting 1000 at?
Why would I want to be doing the same?
--
Dan Espen
Mut...@dastardlyhq.com
Aug 6, 2022, 11:05:57 AM8/6/22
to
On Sat, 06 Aug 2022 08:13:34 -0400
Dan Espen <dan1...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>
>> On Thu, 04 Aug 2022 23:23:05 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>That's why we always either use she-bang, or use the invoke the script
>>
>> Wtf is "she" for? Its either called hash or pound depending on what side of
>> the atlantic you're on. Its never called "she" and I've never heard anyone
>> anywhere ever refer to it like this.
>
>Here, have a look:
>
>https://en.wikipedia.org/wiki/Shebang_(Unix)
Doesn't explain why though I skim read it.
Dan Espen <dan1...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>
>> On Thu, 04 Aug 2022 23:23:05 GMT
>> sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>That's why we always either use she-bang, or use the invoke the script
>>
>> Wtf is "she" for? Its either called hash or pound depending on what side of
>> the atlantic you're on. Its never called "she" and I've never heard anyone
>> anywhere ever refer to it like this.
>
>Here, have a look:
>
>https://en.wikipedia.org/wiki/Shebang_(Unix)
>Someone seems to be batting 1000.
Scott Lurndal
Aug 6, 2022, 11:25:25 AM8/6/22
to
Mut...@dastardlyhq.com writes:
>On Thu, 04 Aug 2022 23:23:05 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>That's why we always either use she-bang, or use the invoke the script
>
>Wtf is "she" for? Its either called hash or pound depending on what side of
>the atlantic you're on.
It is also known as "sharp" by musicians.
>On Thu, 04 Aug 2022 23:23:05 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>That's why we always either use she-bang, or use the invoke the script
>
>Wtf is "she" for? Its either called hash or pound depending on what side of
>the atlantic you're on.
Mut...@dastardlyhq.com
Aug 6, 2022, 11:28:56 AM8/6/22
to
On Sat, 06 Aug 2022 15:25:23 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Mut...@dastardlyhq.com writes:
>>On Thu, 04 Aug 2022 23:23:05 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>That's why we always either use she-bang, or use the invoke the script
>>
>>Wtf is "she" for? Its either called hash or pound depending on what side of
>>the atlantic you're on.
>
>It is also known as "sharp" by musicians.
True. Also MS with C# :)
>Mut...@dastardlyhq.com writes:
>>On Thu, 04 Aug 2022 23:23:05 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>>That's why we always either use she-bang, or use the invoke the script
>>
>>Wtf is "she" for? Its either called hash or pound depending on what side of
>>the atlantic you're on.
>
>It is also known as "sharp" by musicians.
Scott Lurndal
Aug 6, 2022, 4:40:23 PM8/6/22
to
Dan Espen
Aug 6, 2022, 5:45:22 PM8/6/22
to
--
Dan Espen
Kaz Kylheku
Aug 6, 2022, 9:43:06 PM8/6/22
to
bang" or "hash bang".
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mut...@dastardlyhq.com
Aug 7, 2022, 9:55:12 AM8/7/22
to
On Sat, 06 Aug 2022 17:45:19 -0400
Dan Espen <dan1...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>
>> On Sat, 06 Aug 2022 08:13:34 -0400
>> Dan Espen <dan1...@gmail.com> wrote:
>>>Mut...@dastardlyhq.com writes:
>>>Someone seems to be batting 1000.
>>
>> Is that some obscure sports analogy?
>
>Not obscure. Easily accessed by doing a search.
You posted it, you explain otherwise STFU.
>Mut...@dastardlyhq.com writes:
>
>> On Sat, 06 Aug 2022 08:13:34 -0400
>> Dan Espen <dan1...@gmail.com> wrote:
>>>Mut...@dastardlyhq.com writes:
>>>Someone seems to be batting 1000.
>>
>> Is that some obscure sports analogy?
>
>Not obscure. Easily accessed by doing a search.
Dan Espen
Aug 7, 2022, 10:31:03 AM8/7/22
to
Mut...@dastardlyhq.com writes:
> On Sat, 06 Aug 2022 17:45:19 -0400
> Dan Espen <dan1...@gmail.com> wrote:
>>Mut...@dastardlyhq.com writes:
>>
>>> On Sat, 06 Aug 2022 08:13:34 -0400
>>> Dan Espen <dan1...@gmail.com> wrote:
>>>>Mut...@dastardlyhq.com writes:
>>>>Someone seems to be batting 1000.
>>>
>>> Is that some obscure sports analogy?
>>
>>Not obscure. Easily accessed by doing a search.
>
> You posted it, you explain otherwise STFU.
Oh sorry, didn't realize you were of limited abilities.
> On Sat, 06 Aug 2022 17:45:19 -0400
> Dan Espen <dan1...@gmail.com> wrote:
>>Mut...@dastardlyhq.com writes:
>>
>>> On Sat, 06 Aug 2022 08:13:34 -0400
>>> Dan Espen <dan1...@gmail.com> wrote:
>>>>Mut...@dastardlyhq.com writes:
>>>>Someone seems to be batting 1000.
>>>
>>> Is that some obscure sports analogy?
>>
>>Not obscure. Easily accessed by doing a search.
>
> You posted it, you explain otherwise STFU.
https://en.wiktionary.org/wiki/bat_a_thousand
--
Dan Espen
Mut...@dastardlyhq.com
Aug 8, 2022, 3:56:19 AM8/8/22
to
On Sun, 07 Aug 2022 10:31:00 -0400
Dan Espen <dan1...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>
>> On Sat, 06 Aug 2022 17:45:19 -0400
>> Dan Espen <dan1...@gmail.com> wrote:
>>>Mut...@dastardlyhq.com writes:
>>>
>>>> On Sat, 06 Aug 2022 08:13:34 -0400
>>>> Dan Espen <dan1...@gmail.com> wrote:
>>>>>Mut...@dastardlyhq.com writes:
>>>>>Someone seems to be batting 1000.
>>>>
>>>> Is that some obscure sports analogy?
>>>
>>>Not obscure. Easily accessed by doing a search.
>>
>> You posted it, you explain otherwise STFU.
>
>Oh sorry, didn't realize you were of limited abilities.
>
>https://en.wiktionary.org/wiki/bat_a_thousand
More a case of limited giving a shit.
>Mut...@dastardlyhq.com writes:
>
>> On Sat, 06 Aug 2022 17:45:19 -0400
>> Dan Espen <dan1...@gmail.com> wrote:
>>>Mut...@dastardlyhq.com writes:
>>>
>>>> On Sat, 06 Aug 2022 08:13:34 -0400
>>>> Dan Espen <dan1...@gmail.com> wrote:
>>>>>Mut...@dastardlyhq.com writes:
>>>>>Someone seems to be batting 1000.
>>>>
>>>> Is that some obscure sports analogy?
>>>
>>>Not obscure. Easily accessed by doing a search.
>>
>> You posted it, you explain otherwise STFU.
>
>Oh sorry, didn't realize you were of limited abilities.
>
>https://en.wiktionary.org/wiki/bat_a_thousand
0 new messages