[PATCH] Ash support for replace and subsitution

[Paul Smith]

On Mon, 2008-03-24 at 22:56 +0100, Denys Vlasenko wrote:
> > > Well, maybe we should wait for a ruling by Denys or someone.  I'd really
> > > love to have a POSIX-standard shell in busybox, and I had this idea that
> > > that was a design goal of ash.

> From the practical point-of-view, bbox need standard-compliant shell.
> ash is (trying to be) such a shell.

Sounds good.

> Above standard-compliance, bbox needs a shell which emulates bash.
> This is purely from practucal point-of-view: most Linux installations use
> bash as the primary shell => most scripts are written for bash
> (when they use non-standard bash-isms).

This is changing, though: Ubuntu and all derivatives have
declared /bin/sh is dash, which is a basic POSIX shell and does NOT have
any bash features or extensions.

Yes, this causes pain when some non-portable scripts that declare
#!/bin/sh but actually use bash features are run on Ubuntu, but those
are reported as bugs to the upstream developers and so these problems
are gradually being fixed.  So far the Ubuntu devs have fought the good
fight and held the line against the "all /bin/sh is bash" crowd.

> Bashisms in ash can be guarded by ENABLE_FEATURE_BASH_COMPAT,
> in order to make standard lawyer-esque people happier.

This would be good, speaking as a standard lawyer-esque person :-).

> > > But I could be wrong.  For example, the extended test notation [[ ... ]]
> > > is not POSIX, but (according to your patch; I haven't checked it myself)
> > > it's already supported.
> 
> SUSv3 says (see shell/susv3_doc.tar.bz2):
> 
> "The following words may be recognized as reserved words on some implementations
> (when none of the characters are quoted), causing unspecified results:
>     [[ ]] function select"

Yep, I'm aware the POSIX reserves the keyword and that bash implements
it, but it's not a feature defined by POSIX; IMO it should be optionally
enabled as a non-standard feature.

Which I think, according to James, it is.

> So, it's indeed a bash'ism. (So far I don't see how it differs from "test
> and "[". huh?)

The main difference is that [[ is always a shell builtin, while [ and
test were often separate programs (and still must work the as such, even
if they're built into more modern shells).  There are some differences
allowed by it being required to be a shell built-in, around when word
splitting and expansion are performed, that remove some idiosyncrasies
of the traditional test command.  The docs say in particular that word
splitting is NOT performed on items between [[ and ]], which is a big
difference from test/[.

> Just imagine how bad it will be if "shell scripts which use
> busybox ash's extensions" will appear!

*shudder*!