From Newsgroup: comp.unix.shell

On 2025-01-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

This is obviously deliberate, and I see similar code (without the posixly_correct condition) in bash 1.05 from 1990.

According to Wikipedia, POSIX began in 1988, and the initial
release of bash was in 1989, just a year later. Obviously the
authors thought that expanding literal '~'s in $PATH was a good
idea at the time, and it's not suprising that they didn't pay much
attention to POSIX. It would have been nice if they'd documented it.

In recent years, I've been wondering about the early history of
Bash, but cursory searches came up empty. Versions before 1.14
have even been expunged from ftp.gnu.org.

My vague impression is that Bash started as an attempt to combine
csh and sh, but it's not clear to me how soon people noticed the
infeasibility and pivoted to a sh-based model. Or maybe that's not
at all how it happened.

If anybody has pointers to the early history or old source code,
I'd love to know.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Christian Weisgerber <naddy@mips.inka.de> writes:

On 2025-01-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

This is obviously deliberate, and I see similar code (without the
posixly_correct condition) in bash 1.05 from 1990.

According to Wikipedia, POSIX began in 1988, and the initial
release of bash was in 1989, just a year later. Obviously the
authors thought that expanding literal '~'s in $PATH was a good
idea at the time, and it's not suprising that they didn't pay much
attention to POSIX. It would have been nice if they'd documented it.

In recent years, I've been wondering about the early history of
Bash, but cursory searches came up empty. Versions before 1.14
have even been expunged from ftp.gnu.org.

My vague impression is that Bash started as an attempt to combine
csh and sh, but it's not clear to me how soon people noticed the infeasibility and pivoted to a sh-based model. Or maybe that's not
at all how it happened.

If anybody has pointers to the early history or old source code,
I'd love to know.

The oldest version I've found is 1.05.

bash is maintained in a git repo at

git://git.savannah.gnu.org/bash.git

but the earliest commit is :

commit 726f63884db0132f01745f1fb4465e6621088ccf
Author: Jari Aalto <jari.aalto@cante.net>
Date: 1996-08-26 18:22:31 +0000

Imported from ../bash-1.14.7.tar.gz.

so it doesn't have the full history.

I downloaded a tarball for bash 1.05 from oldlinux.org.
It's been reorganized since then and moved to GitHub.

https://github.com/oldlinux-web/oldlinux-files/tree/master/gnu/bash
has 1.05, 1.13.5, and 1.14, from 1990, 1993, and 1994, respectively.
The direct download URLs are:

https://github.com/oldlinux-web/oldlinux-files/raw/refs/heads/master/gnu/bash/bash-1.05-linux.tar.gz
https://github.com/oldlinux-web/oldlinux-files/raw/refs/heads/master/gnu/bash/bash-1.13.5.tar.gz
https://github.com/oldlinux-web/oldlinux-files/raw/refs/heads/master/gnu/bash/bash-1.14.tar.gz

bash-1.05-linux.tar.gz isn't just the original bash 1.05 sources. The
tarball includes object and executable files from a build apparently
done in 2004 for a Linux i386 system. There are also some changes to
some of the source files to let it build on Linux.

I've just created a GitHub repo that includes the original
bash-1.05.tar.gz, which doesn't appear to be available elsewhere :

https://github.com/Keith-S-Thompson/old-bash
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Christian Weisgerber <naddy@mips.inka.de> writes:
[...]

My vague impression is that Bash started as an attempt to combine
csh and sh, but it's not clear to me how soon people noticed the infeasibility and pivoted to a sh-based model. Or maybe that's not
at all how it happened.

The Bash README says that

Bash is the GNU Project's Bourne Again SHell, a complete
implementation of the POSIX shell spec, but also with interactive
command line editing, job control on architectures that support
it, csh-like features such as history substitution and brace
expansion, and a slew of other features.

My understanding is that it was always intended to be POSIX-based
(also implied by the name "Bourne Again SHell", where the POSIX
shell spec is based on the Bourne shell), with some additional
features copied from csh and elsewhere.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sun, 26 Jan 2025 15:51:33 -0800, Keith Thompson wrote:

... (also implied by the name "Bourne Again SHell" ...

Ah, the Reagan era ...
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 27.01.2025 19:30, Kaz Kylheku wrote:

I don't suspect this problem intersects with the issue we are talking
about, but it's hard to be sure about a negative without doing a bunch
of work.

(It's worth a subject switch.)

The ability to use a Unicode slash in a filename on POSIX systems,
thanks to UTF-8, is mostly a good thing, in my view.

I recall an old discussion on the topic, many many years ago.

I generally avoid, for example, using spaces (and yet more so any
exotic control characters) in filenames. - It always stroke me as
if it would produce more hassle than [principle] gain. (Thinking
of 'Backspace', 'Delete', 'CR', 'NL', or even 'Bell', etc.)

I also think that a fileNAME should not be a fileNOVEL or carry all
or part of a file's meta-data. For me it would certainly be okay to
have the 'printable' characters available. - I suppose (given what
excessive filenames are regularly used) that many people will see
that differently.

Back these days someone had pointed out that it's actually helpful
if you have only few restrictions ('\0' and '/') on characters; it
makes it possible to support "non-ASCII file systems" based on that
underlying primitive design. - That's certainly a valid point.

The point (made upthread) with the non-ASCII slash character makes
me doubt, though. Wouldn't such exploits like you constructed with
the "literal '~'" topic be also possible with "fake" slashes?

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-01-27, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Back these days someone had pointed out that it's actually helpful
if you have only few restrictions ('\0' and '/') on characters; it
makes it possible to support "non-ASCII file systems" based on that underlying primitive design. - That's certainly a valid point.

Today, billions of people around the world have files named using their
native scripts.

The point (made upthread) with the non-ASCII slash character makes
me doubt, though. Wouldn't such exploits like you constructed with
the "literal '~'" topic be also possible with "fake" slashes?

Sure; say the user adds "/home/foo/bin" to their PATH, but somehow their
editor flips the slashes to the Unicode U+2215 slash, then it's just one relative path component that is susceptible to hijack.

The user would have to somehow not notice that their /home/bin/foo PATH
element is not actually working: programs in that directory are not
being found.

If the shell did something silly, namely map Unicode slashes to ASCII equivalents when doing its own procesing of PATH, then that user would
be fooled into thinking that the path component is correct.

That's kind of what Bash is doing with the tilde; for its own purposes,
it's turning, in the leading position, a dumb tilde into a smart tilde,
which we can almost regard as different characters.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2