[ANN] KornShell 93u+m/1.0.0

[Martijn Dekker]

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

[mut...@dastardlyhq.com]

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.

[Auric__]

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.

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

[Aragorn]

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 =

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

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

[Scott Lurndal]

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

[John McCue]

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

[Eli the Bearded]

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.

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

[Martijn Dekker]

Op 02-08-22 om 20:06 schreef mut...@dastardlyhq.com:

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

[Martijn Dekker]

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

[Martijn Dekker]

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

[Martijn Dekker]

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

[Helmut Waitzmann]

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

[Helmut Waitzmann]

[Janis Papanagnou]

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

[Janis Papanagnou]

On 03.08.2022 01:05, John McCue wrote:
> Follow-ups trimmed to comp.unix.shell
> In comp.unix.shell mut...@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

[mut...@dastardlyhq.com]

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

[mut...@dastardlyhq.com]

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.

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

[mut...@dastardlyhq.com]

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]

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

[John McCue]

Trimmed to comp.unix.shell

In comp.unix.shell mut...@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>

[Scott Lurndal]

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?

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

[Eli the Bearded]

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

In comp.unix.shell, <mut...@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

[Keith Thompson]

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.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Gary R. Schmidt]

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
well. (Yes, Solaris is still big in the corporate data centres of the
rising sun.)

Cheers,
Gary B-)

[Aragorn]

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.

[John McCue]

Eli the Bearded <*@eli.users.panix.com> wrote:

<snip>

> 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 actually like this feature. At least one brain-dead
proprietary java application insist you supply the ID/PW
using command line arguments. At least that info is not
in history if I need to run a manual test.

But using ps(1), I can get admin IDs/Passwords if I want to
from the jobs the admins scheduled (I do not though).

One has to love closed source :(

[John D Groenveld]

In article <2lprri-...@paranoia.mcleod-schmidt.id.au>,

Gary R. Schmidt <grsc...@acm.org> wrote:
>zsh is big in Japan, not just on Linux boxes but on Solaris systems as

I switched to zsh as my preferred interactive shell, but code
in ksh on illumos, FreeBSD, Linux and Solaris.

Kudos to Martijn for leading ksh's revival.
John
groe...@acm.org

[Helmut Waitzmann]

mut...@dastardlyhq.com:

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

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

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

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

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

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

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

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

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

Then everybody may consider subscribing to the newsgroup.


>Ignored.
>

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

[Christian Weisgerber]

On 2022-08-02, Scott Lurndal <sc...@slp53.sl.home> wrote:

> The only people in my experience that use tcsh are
> RTL designers and verification engineers. It's quite common in the
> Synoposys/Cadence world,

It's the default shell on FreeBSD. I'll go out on a limb and say
that most people don't change it there.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Helmut Waitzmann]

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

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

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

So it's debatable, whether Martijn shouldn't have posted his

announcement to “comp.unix.programmer”.

[Kenny McCormack]

In article <slrntenmkk...@lorvorc.mips.inka.de>,

Christian Weisgerber <na...@mips.inka.de> wrote:
>On 2022-08-02, Scott Lurndal <sc...@slp53.sl.home> wrote:
>
>> The only people in my experience that use tcsh are
>> RTL designers and verification engineers. It's quite common in the
>> Synoposys/Cadence world,
>
>It's the default shell on FreeBSD. I'll go out on a limb and say
>that most people don't change it there.

tcsh has the best command line vi emulation of any of the shells I've
tested (and that includes all the ones mentioned in this thread).

I think that is tcsh's main reason for continued relevance.

--
Note that Oprah actually is all the things that The Donald only wishes he were.
For one thing, she actually *is* a billionaire. She's also actually self-made,
came from nothing, knows how to run businesses, never went bankrupt, is smart
and is mentally stable.

[mut...@dastardlyhq.com]

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.

[Eli the Bearded]

In comp.unix.shell, John McCue <jmc...@SPAMisBADgmail.com> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> It's a _huge_ misfeature to me that lines beginning with a space are
>> excluded from history by default.

> I actually like this feature. At least one brain-dead
> proprietary java application insist you supply the ID/PW
> using command line arguments. At least that info is not
> in history if I need to run a manual test.

$ umask 0077
$ cat > /tmp/foo
password=blahdeblah
id=827240261886336764177
^D
$ . /tmp/foo
$ rm /tmp/foo
$ bad-application --password "$password" --id "$id"

> But using ps(1), I can get admin IDs/Passwords

Yeah, serious drawback for a long lived command, and race condition
concern for short-lived one.

Lots of _other_ places you can find passwords in history. Maybe you use
vim to edit /tmp/foo and get it in .viminfo. Maybe you set the password
in mysql and the command is in .mysql_history (I have recovered
passwords other people changed via that leak). I'm sure the list goes
on, and computer forensics types could share stories.

> One has to love closed source :(

Sufficiently complicated open source is bad enough.

I recently reported a bug in Gnu bc, only to be told that it's
readline() issue and the maintainer doesn't know how to resolve it.
bug-bc@gnu appears to be an alias for the maintainer's address rather
than a list, so I can't post a link and must assume the message back to
me is private.

https://lists.gnu.org/mailman/listinfo/bug-bc
"No such list bug-bc"

Elijah
------
would like source to bc implementation other than Gnu or dc frontend

[Scott Lurndal]

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

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

[mut...@dastardlyhq.com]

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?

[Scott Lurndal]

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

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

[mut...@dastardlyhq.com]

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.

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

[Dan Espen]

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
a hash bang. Feel free to not believe me too.

--
Dan Espen

[Ed Morton]

Likewise, 100% of the shell scripts shipped to customers or used as a
tool has a shebang. If you don't know what a shebang is, see
https://en.wikipedia.org/wiki/Shebang_(Unix) or just google
https://www.google.com/search?q=shebang+shell+script.

Ed.

[Scott Lurndal]

Yes, that experience tells me that don't want to rely on that behavior,
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.

[Keith Thompson]

sc...@slp53.sl.home (Scott Lurndal) writes:
> mut...@dastardlyhq.com writes:
>>On Thu, 04 Aug 2022 20:28:06 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:

[...]

>>>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.
>
> Yes, that experience tells me that don't want to rely on that behavior,
> 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.

In a quick experiment, it seems that such a script is invoked either by
current shell or by /bin/sh, depending on which shell I invoke it from.
I don't see any cases where it depends on $SHELL.

The behavior may vary on different systems -- which is why I also avoid
relying on it.

[Geoff Clare]

Ed Morton wrote:

> On 8/4/2022 4:06 PM, Dan Espen wrote:
>> 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
>> a hash bang. Feel free to not believe me too.
>>
>
> Likewise, 100% of the shell scripts shipped to customers or used as a
> tool has a shebang.

Where I work 100% of (hundreds of) shell scripts shipped to customers
do not have a #! line. That's because they are required to conform to
POSIX, and POSIX says that if the first line starts with #! the results
are unspecified.

--
Geoff Clare <net...@gclare.org.uk>

[Scott Lurndal]

Keith Thompson <Keith.S.T...@gmail.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) writes:
>> mut...@dastardlyhq.com writes:
>>>On Thu, 04 Aug 2022 20:28:06 GMT
>>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>[...]
>>>>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.
>>
>> Yes, that experience tells me that don't want to rely on that behavior,
>> 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.
>
>In a quick experiment, it seems that such a script is invoked either by
>current shell or by /bin/sh, depending on which shell I invoke it from.
>I don't see any cases where it depends on $SHELL.
>
>The behavior may vary on different systems -- which is why I also avoid
>relying on it.

Open Group says this (under execle):

There are two distinct ways in which the contents of the process image
file may cause the execution to fail, distinguished by the setting of
errno to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the
cases where the other members of the exec family of functions would fail
and set errno to [ENOEXEC], the execlp() and execvp() functions shall
execute a command interpreter and the environment of the executed command
shall be as if the process invoked the sh utility using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file
is the process image file, and for execvp(), where arg0, arg1, and
so on correspond to the values passed to execvp() in argv[0], argv[1], and so on.

I've worked with C library implementations that derive <shell path> from $SHELL
if set.

[Keith Thompson]

And for at least some shells, executing a file doesn't just invoke one
of the exec*() functions. When I use execvp() in a C program to execute
a script with no "#!" line, it uses /bin/sh. When I run the same script
from bash, it uses the currently running bash, even when the current
bash is neither $SHELL nor /bin/bash.

[John McCue]

Eli the Bearded <*@eli.users.panix.com> wrote:

<snip>

>
> $ umask 0077
> $ cat > /tmp/foo
> password=blahdeblah
> id=827240261886336764177
> ^D
> $ . /tmp/foo
> $ rm /tmp/foo
> $ bad-application --password "$password" --id "$id"

I tried to get the admins to do smething like this
a few times years ago, but no luck and I gave up.

As a developer, I have limited access, just enough to
develop/support. A couple of years ago I sent the admins
the ps output but nothing was done. I suspect the vendor
said you have to do it this way, I can see the vendor saying
that, so they were afraid of making a change.

We have new admins now, so I may make another attempt to
show them the hole and see what happens.

[John McCue]

Geoff Clare <ge...@clare.see-my-signature.invalid> wrote:
<snip>

>
> Where I work 100% of (hundreds of) shell scripts shipped to customers
> do not have a #! line. That's because they are required to conform to
> POSIX, and POSIX says that if the first line starts with #! the results
> are unspecified.

I never read POSIX, but '#!' statement is very odd. I do
not doubt POSIX says that since I think it was first done
many decades ago by a US Gov committee.

That statement would make my head spin, as you know, a '#'
is a comment in all the shells I am aware of.
The phrase "good enough for Gov Work" comes to mind :)

[Keith Thompson]

John McCue <jmc...@neutron.hsd1.ma.comcast.net> writes:
> Geoff Clare <ge...@clare.see-my-signature.invalid> wrote:
> <snip>
>>
>> Where I work 100% of (hundreds of) shell scripts shipped to customers
>> do not have a #! line. That's because they are required to conform to
>> POSIX, and POSIX says that if the first line starts with #! the results
>> are unspecified.
>
> I never read POSIX, but '#!' statement is very odd. I do
> not doubt POSIX says that since I think it was first done
> many decades ago by a US Gov committee.

IEEE, not the US Government.

> That statement would make my head spin, as you know, a '#'
> is a comment in all the shells I am aware of.
> The phrase "good enough for Gov Work" comes to mind :)

Yes, # introduces a comment in most shells.

I haven't found that statement in POSIX about #!, but I presume the
reason is that saying it's unspecified allows the usual implementation
while not requiring POSIX to specify the behavior.

If POSIX said nothing about #! then it would imply that it has to be
treated as an ordinary comment.

Since the #! feature is nearly universal for Unix-like systems and
predates POSIX, I'm not sure why POSIX didn't standardize it.

[Lew Pitcher]

On Fri, 05 Aug 2022 12:32:01 -0700, Keith Thompson wrote:

> John McCue <jmc...@neutron.hsd1.ma.comcast.net> writes:
>> Geoff Clare <ge...@clare.see-my-signature.invalid> wrote:
>> <snip>
>>>
>>> Where I work 100% of (hundreds of) shell scripts shipped to customers
>>> do not have a #! line. That's because they are required to conform to
>>> POSIX, and POSIX says that if the first line starts with #! the results
>>> are unspecified.
>>
>> I never read POSIX, but '#!' statement is very odd. I do
>> not doubt POSIX says that since I think it was first done
>> many decades ago by a US Gov committee.
>
> IEEE, not the US Government.
>
>> That statement would make my head spin, as you know, a '#'
>> is a comment in all the shells I am aware of.
>> The phrase "good enough for Gov Work" comes to mind :)
>
> Yes, # introduces a comment in most shells.
>
> I haven't found that statement in POSIX about #!, but I presume the
> reason is that saying it's unspecified allows the usual implementation
> while not requiring POSIX to specify the behavior.

I'd assume this as well.

The Open Group Base Specifications Issue 7, 2018 edition
IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)

Chapter 2 Shell Command Language
2.1 Shell Introduction

"The shell reads its input from a file (see sh), from the -c option
or from the system() and popen() functions defined in the System
Interfaces volume of POSIX.1-2017. If the first line of a file of
shell commands starts with the characters "#!", the results are
unspecified."

>
> If POSIX said nothing about #! then it would imply that it has to be
> treated as an ordinary comment.
>
> Since the #! feature is nearly universal for Unix-like systems and
> predates POSIX, I'm not sure why POSIX didn't standardize it.

I imagine that, because the #! names an interpreter, and that interpreter
isn't part of the Shell specifications, the POSIX Shell documentation can't
make any guarantees or assumptions about how that (unspecified) interpreter
might affect the execution of the standardized shell code. For instance,
if the #! names the Whitespace programming language interpreter
(see https://en.wikipedia.org/wiki/Whitespace_(programming_language) ) as
it's interpreter, the shell code still represents a valid program, but
will not generate the results expected from a POSIX Shell program.


--
Lew Pitcher
"In Skills, We Trust"

[Eli the Bearded]

In comp.unix.shell, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> On Fri, 05 Aug 2022 12:32:01 -0700, Keith Thompson wrote:
>> Yes, # introduces a comment in most shells.

And indeed, #! is a comment _to the shell_. It's not a comment to the
kernel running exec(), there it specifies what intrepreter to use. (ELF
and a.out are other interpreters that have different file identification
methods.)

>> I haven't found that statement in POSIX about #!, but I presume the
>> reason is that saying it's unspecified allows the usual implementation
>> while not requiring POSIX to specify the behavior.
>
> I'd assume this as well.

Some unix systems have required a space, eg '#! /bin/sh' and some
require no space, so right away I can imagine POSIX has trouble. Then there's the
issue of arguments on the #! line.

Tools like Perl might examine the #! line and do intelligent things with
it. Or may see ^# and just treat it as another comment.

$ cat > /tmp/eg
#!/bin/ksh
ps -lp $$
^D
$ perl /tmp/eg
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
13785 7025 2460 0 85 0 18036 1836 pause S+ pts/34 0:00.01 /bin/ksh
$

Elijah
------
#!/bin/env is another fun quirk

[Keith Thompson]

Eli the Bearded <*@eli.users.panix.com> writes:
> In comp.unix.shell, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
>> On Fri, 05 Aug 2022 12:32:01 -0700, Keith Thompson wrote:
>>> Yes, # introduces a comment in most shells.
>
> And indeed, #! is a comment _to the shell_. It's not a comment to the
> kernel running exec(), there it specifies what intrepreter to use. (ELF
> and a.out are other interpreters that have different file identification
> methods.)
>
>>> I haven't found that statement in POSIX about #!, but I presume the
>>> reason is that saying it's unspecified allows the usual implementation
>>> while not requiring POSIX to specify the behavior.
>>
>> I'd assume this as well.
>
> Some unix systems have required a space, eg '#! /bin/sh' and some
> require no space, so right away I can imagine POSIX has trouble. Then there's the
> issue of arguments on the #! line.

I've never heard of a system that requires a space after the "#!", and I
don't *think* I've heard of a system that forbids it. As far as I know,
it's always been optional.

Arguments after the command name are certainly an issue. But POSIX
*could* have documented #! and left some aspects of it unspecified. (If
it did so, it wouldn't be in the "Shell Command Language" section but
under system(), popen(), and/or exec*(), since a script with a #! isn't
necessarily a shell script.)

There are some non-normative references to #! in POSIX. For example,
the section on environ, execl, et al says:

Another way that some historical implementations handle shell
scripts is by recognizing the first two bytes of the file as the
character string "#!" and using the remainder of the first line of
the file as the name of the command interpreter to execute.

> Tools like Perl might examine the #! line and do intelligent things with
> it. Or may see ^# and just treat it as another comment.
>
> $ cat > /tmp/eg
> #!/bin/ksh
> ps -lp $$
> ^D
> $ perl /tmp/eg
> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 13785 7025 2460 0 85 0 18036 1836 pause S+ pts/34 0:00.01 /bin/ksh
> $
>
> Elijah
> ------
> #!/bin/env is another fun quirk

/bin/env doesn't exist on my system (Ubuntu); it's /usr/bin/env.

[Kaz Kylheku]

What? Only sourcing a script should use the current shell; sourcing
isn't execution.

By "run from bash" are you referring to passing the script as a command
line argument as in

bash ./script

?

That bash instance will of course read and run the script. But if you
give bash a command via standard input:

bash$ ./script

that must run it in a child process..

When I do this:

$ echo ./testscript | strace -o log bash

The strace log has:

read(0, ".", 1) = 1
read(0, "/", 1) = 1
read(0, "t", 1) = 1
read(0, "e", 1) = 1
read(0, "s", 1) = 1
read(0, "t", 1) = 1
read(0, "s", 1) = 1
read(0, "c", 1) = 1
read(0, "r", 1) = 1
read(0, "i", 1) = 1
read(0, "p", 1) = 1
read(0, "t", 1) = 1
read(0, "\n", 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f8aae8) = 1407
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1407, si_uid=500, si_status=0, si_utime=0, si_stime=0} ---

Bash reads the command and spawns a process.

Moreover, if we trace this again with -f to see what the child is doing:

1670 execve("./testscript", ["./testscript"], 0x1e00500 /* 24 vars */) = -1 ENOEXEC (Exec format error)
1670 openat(AT_FDCWD, "./testscript", O_RDONLY|O_LARGEFILE) = 3
1670 read(3, "FOO=abc\ncd /\n", 128) = 13
1670 close(3) = 0

See: execve happens.

It cannot be that bash would read a command and just run it in the
current shell, if that command isn't a built-in or user-defined
function.

It also cannot be that bash would just fork a child process, and
then interpret the script without exec; a script without hash bang
has to be given the proper treatment through exec to choose
the interpreter in a consistent way.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[Mut...@dastardlyhq.com]

I wasn't talking about commercially shipped scripts, I was talking about
internal ones as I'm sure you understood.

[Mut...@dastardlyhq.com]

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.

[Janis Papanagnou]

In the past we rarely shipped _scripts_ to customers, rather mostly
large program systems or single binaries or complete runtime packages.
Anyway, an executable script has to be started with the appropriate
(well defined) interpreter, so an explicit shebang definition would
be the cleanest way, IMO. (Personally and privately I explicitly use
the interpreter on the script file in most cases.) But what we (or
our company) ships is beyond a generally valid statement. If I inspect
the PATH on my Linux system and the script files located there I find
round about 1000 scripts, all with a #! line and with the interpreters
depicted in the list

324 #!/bin/sh
152 #!/usr/bin/perl
132 #!/usr/bin/perl -w
92 #!/usr/bin/python
72 #! /bin/sh
56 #!/bin/bash
37 #! /usr/bin/perl
31 #!/bin/sh -e
24 #! /usr/bin/python
15 #! /usr/bin/env
13 #!/usr/bin/env python
11 #! /bin/bash
6 #!/bin/sh -
5 #!/usr/bin/ruby1.8
3 #!/bin/bash -e
3 #! /usr/bin/python2.7
2 #!/usr/bin/wish
2 #!/usr/bin/env ruby
1 #!/usr/bin/python2.7
1 #!/usr/bin/python -Es
1 #!/usr/bin/perl -wl
1 #!/usr/bin/perl --
1 #!/usr/bin/guile -s
1 #!/usr/bin/env perl
1 #!/usr/bin/env nickle
1 #!/usr/bin/env bash
1 #!/bin/sh -f
1 #!/bin/sh -eu
1 #!/bin/mksh
1 #! /usr/bin/python3


Janis

[Janis Papanagnou]

You find hints here: https://www.in-ulm.de/~mascheck/various/shebang/

Janis

[Richard Kettlewell]

People have been calling it that for ages. I’m not a fan but it’s not
new.

--
https://www.greenend.org.uk/rjk/

[Ed Morton]

Not sure I've ever heard it called anything other than a shebang prior
to this discussion but anyway, I already provided you a reference for it
at https://en.wikipedia.org/wiki/Shebang_(Unix) and see also
https://unix.stackexchange.com/questions/149045/why-is-shebang-called-shebang
for suggestions that it's derived from either of these:

haSH BANG
SHarp BANG

given that # is sometimes referred to as a hash or sharp character and !
is sometimes referred to as a bang character.

Regards,

Ed.

[Dan Espen]

No, no way was that even implied.

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]

Here, have a look:

https://en.wikipedia.org/wiki/Shebang_(Unix)

Someone seems to be batting 1000.

--
Dan Espen

[Kenny McCormack]

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.

--
Atheism:
It's like being the only sober person in the car, and nobody will let you drive.

[Dan Espen]

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

I've never heard it called that and I've been using *nix for 30 years. Perhaps
its an american thing.

[Mut...@dastardlyhq.com]

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.

>Someone seems to be batting 1000.

Is that some obscure sports analogy?

[Scott Lurndal]

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.

[Mut...@dastardlyhq.com]

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

[David W. Hodgins]

Regarding the # character, I was taught it was called a number sign.
https://en.wikipedia.org/wiki/Number_sign
kcharselect agrees, Character: # U+0023, Name: NUMBER SIGN
or a sharp in musical notation.

I didn't here the term hash sign used for it till I started using usenet.
As for calling it the pound sign, I assume that's because US layout keyboards
don't have a £ key.

Regards, Dave Hodgins

[Christian Weisgerber]

On 2022-08-06, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> 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.
>>
>>People have been calling it that for ages. I’m not a fan but it’s not
>>new.
>
> I've never heard it called that and I've been using *nix for 30 years. Perhaps
> its an american thing.

The combination of #! at the start of a script has been called a
"shebang" for decades.

Nobody is calling a single # a "she".

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Kaz Kylheku]

On 2022-08-05, Keith Thompson <Keith.S.T...@gmail.com> wrote:

> John McCue <jmc...@neutron.hsd1.ma.comcast.net> writes:
>> Geoff Clare <ge...@clare.see-my-signature.invalid> wrote:
>> <snip>
>>>
>>> Where I work 100% of (hundreds of) shell scripts shipped to customers
>>> do not have a #! line. That's because they are required to conform to
>>> POSIX, and POSIX says that if the first line starts with #! the results
>>> are unspecified.
>>
>> I never read POSIX, but '#!' statement is very odd. I do
>> not doubt POSIX says that since I think it was first done
>> many decades ago by a US Gov committee.
>
> IEEE, not the US Government.
>
>> That statement would make my head spin, as you know, a '#'
>> is a comment in all the shells I am aware of.
>> The phrase "good enough for Gov Work" comes to mind :)
>
> Yes, # introduces a comment in most shells.
>
> I haven't found that statement in POSIX about #!, but I presume the
> reason is that saying it's unspecified allows the usual implementation
> while not requiring POSIX to specify the behavior.

The usual implementation processes #! like a comment, since the
hash bang mechanism is designed to be invisible to an interpreter
which uses # comments, imposing no requirements on it.

Therefore, the only good reason the spec would be bringing in
unspecified behavior in the treatment of a certain shape of comment in a
certain place in the file would be to allow UNusual implementations of
hash bang, where the interpreter has some responsibility in parsing the
hash bang line and possibly deferring to a different interpreter.

One reason why an interpreter would look at the hash bang line specially
would be to parse multiple command line arguments out of it in an
implementation where only one argument is allowed.

#!/path/to/interp --multiple --args --here

Here interp, before processing any other arguments, could open the
script, see the #! and then edit its argument list from that
information.

The POSIX wording has the effect of allowing the above tricks.

[Scott Lurndal]

Which is the source for _SH_e bang.

[Scott Lurndal]

In the US, long before computers, the octothorpe was used as
shorthand for one pound in weight. e.g. 100# == cw.

[Keith Thompson]

No, I mean "./script".

> That bash instance will of course read and run the script. But if you
> give bash a command via standard input:
>
> bash$ ./script
>
> that must run it in a child process..

Yes. The question is how it runs it.

When I said it uses the current shell, I meant that it invokes it using
the current shell's executable, not that it runs it under the current
shell process. I see now that I was unclear about that.

> When I do this:
>
> $ echo ./testscript | strace -o log bash
>
> The strace log has:
>

[snip]

>
> Bash reads the command and spawns a process.
>
> Moreover, if we trace this again with -f to see what the child is doing:
>
> 1670 execve("./testscript", ["./testscript"], 0x1e00500 /* 24 vars */) = -1 ENOEXEC (Exec format error)
> 1670 openat(AT_FDCWD, "./testscript", O_RDONLY|O_LARGEFILE) = 3
> 1670 read(3, "FOO=abc\ncd /\n", 128) = 13
> 1670 close(3) = 0
>
> See: execve happens.
>
> It cannot be that bash would read a command and just run it in the
> current shell, if that command isn't a built-in or user-defined
> function.

Agreed.

> It also cannot be that bash would just fork a child process, and
> then interpret the script without exec; a script without hash bang
> has to be given the proper treatment through exec to choose
> the interpreter in a consistent way.

That doesn't seem to be the case.

Given a script "foo" with no "#!", running "./foo" from a shell prompt
will either invoke /bin/sh with the script name as an argument, or
invoke the executable for the currently running shell with the script
name as an argument, depending on the shell. My experiment indicates
that bash and ksh use themselves, while zsh and dash use sh.

A demonstration on Ubuntu 20.04.04 LTS (note that my default bash is a
newer version than /bin/bash):
========================================
$ echo $BASH_VERSION
5.1.0(1)-release
$ cat foo
# No shebang

if [ "$BASH_VERSION" ] ; then echo "This is bash $BASH_VERSION"
elif [ "$KSH_VERSION" ] ; then echo "This is ksh $KSH_VERSION"
elif [ "$ZSH_VERSION" ] ; then echo "This is zsh $ZSH_VERSION"
else echo "Unknown shell"
fi
ps -f -p $$
$ ./foo
This is bash 5.1.0(1)-release
UID PID PPID C STIME TTY TIME CMD
kst 1930385 1930335 0 13:59 pts/2 00:00:00 bash -l
$ bash -c ./foo
This is bash 5.1.0(1)-release
UID PID PPID C STIME TTY TIME CMD
kst 1930417 1930335 0 14:00 pts/2 00:00:00 bash -c ./foo
$ ksh -c ./foo
This is ksh Version AJM 93u+ 2012-08-01
UID PID PPID C STIME TTY TIME CMD
kst 1930466 1930335 0 14:00 pts/2 00:00:00 ./foo ./foo
$ zsh -c ./foo
Unknown shell
UID PID PPID C STIME TTY TIME CMD
kst 1930470 1930335 0 14:00 pts/2 00:00:00 sh ./foo
$ dash -c ./foo
Unknown shell
UID PID PPID C STIME TTY TIME CMD
kst 1930513 1930512 0 14:00 pts/2 00:00:00 /bin/sh ./foo
$
========================================

(I never write scripts without a #! line, so I hadn't noticed this
behavior until recently.)

[Keith Thompson]

"David W. Hodgins" <dwho...@nomail.afraid.org> writes:

And the '#' symbol is sometimes used to mean pound (weight).

Unicode calls it "NUMBER SIGN". Other names for it are pound sign,
hash, hashtag (in social media), sharp, and octothorp.

https://en.wikipedia.org/wiki/Number_sign

[Keith Thompson]

Dropping de.comp.os.unix.shell and comp.unix.programmer.
Let's stop inundating a German newsgroup with posts in English.

I've never heard the # character called "she", but the #! is very
commonly called a "shebang". The "sh" probably comes from either "haSH"
or "SHell". "Shebang" is an existing word in other contexts, as in "the
whole shebang"; that undoubtedly inspired the choice of abbreviation.

[Dan Espen]

Not obscure. Easily accessed by doing a search.

--
Dan Espen

[David W. Hodgins]

On Sat, 06 Aug 2022 17:11:32 -0400, Keith Thompson <Keith.S.T...@gmail.com> wrote:

> "David W. Hodgins" <dwho...@nomail.afraid.org> writes:
>> On Sat, 06 Aug 2022 07:30:52 -0400, Richard Kettlewell <inv...@invalid.invalid> wrote:
>>
>>> Mut...@dastardlyhq.com writes:
>>>> 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.
>>>
>>> People have been calling it that for ages. I’m not a fan but it’s not
>>> new.
>>
>> Regarding the # character, I was taught it was called a number sign.
>> https://en.wikipedia.org/wiki/Number_sign
>> kcharselect agrees, Character: # U+0023, Name: NUMBER SIGN
>> or a sharp in musical notation.
>>
>> I didn't here the term hash sign used for it till I started using usenet.
>> As for calling it the pound sign, I assume that's because US layout keyboards
>> don't have a £ key.
>
> And the '#' symbol is sometimes used to mean pound (weight).
>
> Unicode calls it "NUMBER SIGN". Other names for it are pound sign,
> hash, hashtag (in social media), sharp, and octothorp.
>
> https://en.wikipedia.org/wiki/Number_sign

Also, I was taught the ! is called an exclamation mark, not a bang.

I read #! as number sign, exclamation mark.

Regards, Dave Hodgins

[Kaz Kylheku]

The prevailing hypotheses are two: that it's a contraction of "sharp
bang" or "hash bang".

[Kaz Kylheku]

On 2022-08-06, Keith Thompson <Keith.S.T...@gmail.com> wrote:

> Kaz Kylheku <480-99...@kylheku.com> writes:
>> Moreover, if we trace this again with -f to see what the child is doing:
>>
>> 1670 execve("./testscript", ["./testscript"], 0x1e00500 /* 24 vars */) = -1 ENOEXEC (Exec format error)
>> 1670 openat(AT_FDCWD, "./testscript", O_RDONLY|O_LARGEFILE) = 3
>> 1670 read(3, "FOO=abc\ncd /\n", 128) = 13
>> 1670 close(3) = 0
>>
>> See: execve happens.
>>
>> It cannot be that bash would read a command and just run it in the
>> current shell, if that command isn't a built-in or user-defined
>> function.
>
> Agreed.

Ah, I missed the -1 return value from execve(). It failed and returned
to the child shell.

By the way, what I didn't show from that log, is that a path search
takes place, looking for bash. It's not clear for what purpose!

1670 stat64(".", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
1670 stat64("/usr/local/sbin/bash", 0xbfd7534c) = -1 ENOENT (No such file or directory)
1670 stat64("/usr/local/bin/bash", 0xbfd7534c) = -1 ENOENT (No such file or directory)
1670 stat64("/usr/sbin/bash", 0xbfd7534c) = -1 ENOENT (No such file or directory)
1670 stat64("/usr/bin/bash", 0xbfd7534c) = -1 ENOENT (No such file or directory)
1670 stat64("/sbin/bash", 0xbfd7534c) = -1 ENOENT (No such file or directory)
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 geteuid32() = 500
1670 getegid32() = 500
1670 getuid32() = 500
1670 getgid32() = 500
1670 access("/bin/bash", X_OK) = 0
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 geteuid32() = 500
1670 getegid32() = 500
1670 getuid32() = 500
1670 getgid32() = 500
1670 access("/bin/bash", R_OK) = 0
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 geteuid32() = 500
1670 getegid32() = 500
1670 getuid32() = 500
1670 getgid32() = 500
1670 access("/bin/bash", X_OK) = 0
1670 stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=1235608, ...}) = 0
1670 geteuid32() = 500
1670 getegid32() = 500
1670 getuid32() = 500
1670 getgid32() = 500
1670 access("/bin/bash", R_OK) = 0
1670 gettimeofday({tv_sec=1659771305, tv_usec=34961}, NULL) = 0
1670 getpid() = 1670
1670 getpgrp() = 1616

Because then then 1670 reads the script and runs it; nothing is done
with /bin/bash. I should try the experiment with bash not being found
in the path; does it make some kind of difference?

> (I never write scripts without a #! line, so I hadn't noticed this
> behavior until recently.)

But you can trade all the sane behavior for POSIX conformance,
so it may be worth it to reconsider? :)

Now here is what happens when I run the same script from a non-shell
process:

[pid 9814] execve("./testscript", ["./testscript"], 0xbfaaef14 /* 58 vars */) = -1 ENOEXEC (Exec format error)
[pid 9814] execve("/bin/sh", ["/bin/sh", "./testscript"], 0xbfaaef14 /* 58 vars */) = 0

The process made a single call to the execvp function in the C library.

This is documented in the Linux Programmer's Manual man page:

In addition, certain errors are treated specially [by the
functions execlp, execvp and execvpe].

If permission is denied for a file (the attempted execve(2)
failed with the error EACCES), these functions will continue
searching the rest of the search path. If no other file is
found, however, they will return with errno set to EACCES.

If the header of a file isn't recognized (the attempted execve(2)
failed with the error ENOEXEC), these functions will
execute the shell (/bin/sh) with the path of the file as its
first argument. (If this attempt fails, no further searching is
done.)

So, if you use execve() on an executable a shell script that has no hash
bang, it won't work; only the "p" functions emulate this. The script
looks executable only to applications that use execvp and friends.

[Gary R. Schmidt]

Been in use here in Oz since the 80s, to my knowledge.

Cheers,
Gary B-)

[Anssi Saari]

Eli the Bearded <*@eli.users.panix.com> writes:

> Note that I provided numbers for usage on NetBSD.

But what's the default shell on NetBSD and is it different on Panix?

[Aragorn]

On 07.08.2022 at 15:22, Anssi Saari scribbled:

> Eli the Bearded <*@eli.users.panix.com> writes:
>
> > Note that I provided numbers for usage on NetBSD.
>
> But what's the default shell on NetBSD and is it different on Panix?

NetBSD uses ash (Almquist SHell) by default.

--
With respect,
= Aragorn =

[Mut...@dastardlyhq.com]

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]

I wonder how long a test match would have to be to bat 1000. A month?
I imagine he's talking about baseball aka the kids game rounders just like
american football is just rugby with body armour and lots of rest breaks for
the fat steroid whales who play it.

[Dan Espen]

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

--
Dan Espen

[Anssi Saari]

Aragorn <thor...@telenet.be> writes:

> On 07.08.2022 at 15:22, Anssi Saari scribbled:
>
>> Eli the Bearded <*@eli.users.panix.com> writes:
>>
>> > Note that I provided numbers for usage on NetBSD.
>>
>> But what's the default shell on NetBSD and is it different on Panix?
>
> NetBSD uses ash (Almquist SHell) by default.

As users' default login shell? In case that wasn't clear.

[Aragorn]

On 07.08.2022 at 20:25, Anssi Saari scribbled:

I believe so, yes. NetBSD aims for full POSIX compliance and ash is a
POSIX shell.

[Keith Thompson]

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.

Be less rude, please. (You could start by not posting English to
de.comp.os.unix.shell, which I've dropped.)

[John McCue]

Anssi Saari <a...@sci.fi> wrote:
> Aragorn <thor...@telenet.be> writes:
<snip>

>> NetBSD uses ash (Almquist SHell) by default.
>
> As users' default login shell? In case that wasn't clear.

When you install NetBSD, yor are prompted to choose the
shell for root. IIRC, the options are:

1. sh (ash)
2. ksh (PDKSH, v5.2.14 99/07/13.2 per man)
3. csh (the real csh, not tcsh)

I picked sh for root.

When creating users, you can choose any shell that is on
the system. I went with tcsh from pkgsrc for my User ID.

John

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

[Kaz Kylheku]

On 2022-08-07, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
> I wonder how long a test match would have to be to bat 1000. A month?

As short as a few seconds?

A rookie participant who has never swung a bat before, let alone played
ball, goes to bat, and happens to hit the one pitch that is thrown.

At that point, his or her batting average is 1000.

[Mut...@dastardlyhq.com]

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]

On Mon, 8 Aug 2022 07:07:23 -0000 (UTC)
Kaz Kylheku <480-99...@kylheku.com> wrote:
>On 2022-08-07, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> I wonder how long a test match would have to be to bat 1000. A month?
>
>As short as a few seconds?
>
>A rookie participant who has never swung a bat before, let alone played
>ball, goes to bat, and happens to hit the one pitch that is thrown.
>
>At that point, his or her batting average is 1000.

No idea what TF you're talking about. I was talking about cricket to an
australian, hence the "test match". In cricket the best you can do in one hit
is a 6. The highest single batsman score in its history is AFAIK 264.

[Gary R. Schmidt]

On 08/08/2022 17:07, Kaz Kylheku wrote:
> On 2022-08-07, Mut...@dastardlyhq.com <Mut...@dastardlyhq.com> wrote:
>> I wonder how long a test match would have to be to bat 1000. A month?
>
> As short as a few seconds?
>
> A rookie participant who has never swung a bat before, let alone played
> ball, goes to bat, and happens to hit the one pitch that is thrown.
>
> At that point, his or her batting average is 1000.
>

Well, in cricket, rather than the jumped-up game of rounders that the
seppos play, having an average of "1000" would mean having averaged 1000
runs over every innings played without being "out":

"How do you calculate batsman average?
To calculate the batting average of any player, you need to divide the
total number of runs scored by that player by the number of times he or
she has got out (or been dismissed). We can calculate the number of
times the player has been dismissed by subtracting the number of not
outs from the number of innings batted."

Which is why Bradman's batting average is 99.94.

Cheers,
Gary B-)

[Geoff Clare]

Keith Thompson wrote:

> Since the #! feature is nearly universal for Unix-like systems and
> predates POSIX, I'm not sure why POSIX didn't standardize it.

I think it is mainly because POSIX doesn't specify pathnames for
utilities. It is very common to start a shell script with #! /bin/sh
but on Solaris 10 and earlier that would get you an old Bourne shell,
not a POSIX conforming shell (which would need #! /usr/xpg4/bin/sh).

So even if POSIX specified #!, portable applications wouldn't be
able to hard-code that line. They would need a config/install process
that finds the right version of sh (or whatever utility) and adds or
updates the #! line.

--
Geoff Clare <net...@gclare.org.uk>

[Keith Thompson]

Sure, but POSIX could have specified the behavior of #! and the meaning
of its argument(s) without depending on any particular pathnames.

[Eli the Bearded]

In comp.unix.shell, Anssi Saari <a...@sci.fi> wrote:
> Eli the Bearded <*@eli.users.panix.com> writes:
> > Note that I provided numbers for usage on NetBSD.
> But what's the default shell on NetBSD

Don't know, but probably not relevant.

> and is it different on Panix?

Users specify shell at time of sign up. The current web form defaults
to bash. When I signed up it was over the phone, and I'm not sure there
was a web form.

I will note that /bin/sh is currently available from chsh, but not from
the web form. That could be why it has such poor numbers.

Also, 'ksh' here is PD KSH, but nothing tells you that. Which is why I
expect real ksh has such low numbers by comparison, real ksh being
'ksh93' makes it sound like an obsolete version.

I don't remember how shell migration was handled when the switch to
NetBSD started.

Elijah
------
wasn't around for the migration from A/UX

[gerg]

David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>
>Also, I was taught the ! is called an exclamation mark, not a bang.
>

Never heard the term "bang path"?

https://en.wikipedia.org/wiki/UUCP#Mail_routing

The Path: header line in your post to this newsgroup looked like this:

Path: reader2.panix.com!panix!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail

though you likely don't care.

-Greg
--
::::::::::::: Greg Andrews ::::: ge...@panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright

[David W. Hodgins]

On Mon, 08 Aug 2022 22:41:02 -0400, gerg <ge...@panix.com> wrote:

> David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>>
>> Also, I was taught the ! is called an exclamation mark, not a bang.
>>
>
> Never heard the term "bang path"?
>
> https://en.wikipedia.org/wiki/UUCP#Mail_routing
>
> The Path: header line in your post to this newsgroup looked like this:
>
> Path: reader2.panix.com!panix!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
>
> though you likely don't care.

I have heard of it, but didn't associate it with the exclamation marks. I thought
it was just a term for explicitly choosing the path.

Regards, Dave Hodgins

[Marco Scholz]

On 2022-08-04, John D Groenveld <groe...@acm.org> wrote:
> In article <2lprri-...@paranoia.mcleod-schmidt.id.au>,

> Gary R. Schmidt <grsc...@acm.org> wrote:

>>zsh is big in Japan, not just on Linux boxes but on Solaris systems as
>

ksh is the default shell on OpenBSD, PD KSH v5.2.14 99/07/13.2.
ksh93 is in ports, AJM 93u+m/1.0.3 2022-08-25

> I switched to zsh as my preferred interactive shell, but code
> in ksh on illumos, FreeBSD, Linux and Solaris.
>
> Kudos to Martijn for leading ksh's revival.

Martijn, keep up the good work!


--
XMPP to...@disroot.org
DB4CE71C8DEF84257AD0B23E4D5934D90226C7F3 00010011 00010011 ▞