Hi,
On 21/11/2022 15:24, Christoph Anton Mitterer wrote:
Hey Harald
On Mon, 2022-11-21 at 13:08 +0000, Harald van Dijk wrote:
This is intentionally accepted, like all non-standard
substitutions, during parsing, but is supposed to raise a
substitution
error at runtime, so that scripts can do
if shell_supports_subst; then
echo ${var//a/b}
else
echo $var | sed s/a/b/g
fi
Parsing this if statement requires parsing both sides of the branch,
even ${var//a/b} will never be evaluated.
Well, while I can understand the merit of this... it may also have some
drawbacks.
Actually performing this substitution should result in an error:
$ dash -c 'echo ${$//1/2}'
dash: 1: Bad substitution
It does here, too.
What the intended behaviour here is though, is unclear. The
substitution
containing ${...//...} is evaluated but the ${...//...} is skipped
because $restrict_path_list is unset.
In the original script, it may be set. I just shortened it.
Sure, but you will not hit this bug if it is set: if it is set, you will
get the Bad substitution error that is expected for that.
Fixing this so it produces "Bad substitution" should be easy, almost
trivial.
I, personally, would like that anyway better.
Conditionally choosing the variant of shell command language during
runtime seems quite fragile.
I'd rather see straight away, that I use something non-supported.
That is reasonable and some shells do issue errors during parsing for
the example I posted earlier. POSIX explicitly makes it unspecified what
happens here; dash has gone the other way.
Is there some bugtracker for dash, so that it doesn't get forgotten?
There is a patch tracker,
<https://patchwork.kernel.org/project/dash/list/>, but I am not aware of
a bug tracker.
Cheers,
Harald van Dijk
Thanks,
Chris.
