[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
${VAR:4@Q} parameter modifiers don't compose
From: |
d+bug-bash |
Subject: |
${VAR:4@Q} parameter modifiers don't compose |
Date: |
Tue, 22 Sep 2020 11:00:07 +1000 (AEST) |
User-agent: |
Alpine 2.22 (DEB 394 2020-01-19) |
Variable transforms such as ${VAR@Q} do not compose with substrings
expansions, eg ${VAR:1:4}.
For example, I expected ${VAR:4@Q} to quote ${VAR:4}, but instead:
-bash: VAR: 4@Q: value too great for base (error token is "4@Q")
This is because parameter value modifiers do not compose; generally
a single value modifier is supported per expansion. The
implementation's common parameter processing code assumes
the modifier's handler requires the full text up to the next
closing '}'.
parameter_brace_expand()
{
...
if (c == ':') want_substring=1;
else if (c == '/') want_patsub=1;
else if (c == '^' or ',' or '~') want_casemode=1;
...
/* Get the rest of the stuff inside the braces. */
if (c && c != RBRACE)
{
value = extract_dollar_brace_string(string,
&sindex, quoted, SX_POSIXEXP | SX_WORD);
}
...
if (want_substring)
{ parameter_brace_substring(,value,); return; }
else if (want_patsub)
{ parameter_brace_patsub(,value,); return; }
else if (want_casemod)
{ parameter_brace_casemod(,value,); return; }
switch (c)
{
case '@':
parameter_brace_transform(,value,); return;
}
}
I have been thinking of a general extension that allows composition
of parameter value modifiers without changing current parsing.
It looks like this:
${VAR{:4}{@Q}^}
The intuitive rule here is that if a normally-terminal modifier
is placed in braces, then it may precede another or a subsequent
final unbraced modifier. Braced operands are constrained to the
next closing brace without ambiguity.
Thoughts?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- ${VAR:4@Q} parameter modifiers don't compose,
d+bug-bash <=