ash variable substitution, quote slash [may be better solution]

Denys Vlasenko vda.linux at googlemail.com
Fri Sep 10 13:54:46 UTC 2010


On Sun, Sep 5, 2010 at 5:10 PM, Harald Becker <ralda at gmx.de> wrote:
>  Hallo Denys!
>> This is all good, but will it solve this?
> v='a/b/c'
> s='b/c'
> r='e/f'
> echo "${v/$s}"
> echo "${v/$s/d}"
> echo "${v/$s/$r}"
> No!

Well, then starting from today there are bugs in ash
which are not present in hush. It now passes a few
quite sadistic tests in
shell/hush_test/hush-vars/var_bash*.tests

(additions to the tests are welcome)

>> That's for var_bash5.tests which ash currently fails.
>
> I missed that topic. Sorry, I'm currently busy and additionally I have
> gone ill again. So I have not got the full discussion. But it solves
> some trouble I just had with busybox 1.17.1 using the substitution feature.
>
>> This can't be fixed by merely tweaking parse_sub_pattern(),
>> because parse_sub_pattern()  gets called _after_ the expansion.
>
> True.
>
>> Therefore I think it's pointless to play with parse_sub_pattern()
>
> It allows the substitutions to be used to change a slash, star, question
> mark or range specification. Which would otherwise not be possible.

My reasoning is that patching an already hopelessly broken
${var/p/r} code in ash just to make it handle a few more cases
without fixing the underlying fatal flaw will make it *more complex*.

And then, when someone will get around and will try to fix it for real,
the complexity added by these hacks will make the proper fix harder.
Especially if "someone" is not the original author.

I speak from recent experience with hush. I have spent about x4 more time
removing old hacks and straightening out backslash handling then
actually fixing ${var/p/r} expansion. And that was _my_ code, so it was
relatively easy.

I would like to not go down that road with ash. We know where
we have a *design* problem. We need to fix it *first*.

-- 
vda


More information about the busybox mailing list