Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11768
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Substring expansion error when offset contains a colon |
| Date | 2015-10-26 09:19 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.1072.1445865588.7904.bug-bash@gnu.org> (permalink) |
| References | <ebef1587-2560-4b8c-b845-ce3d0d39cfda@googlegroups.com> |
On 10/19/15 3:45 AM, grishalevit@gmail.com wrote:
> When using ${parameter:offset:length} expansion, the parser doesn't account for all the ways that a colon can appear in "offset".
>
> For example:
>
> $ echo ${PARAM:${OFFSET:-0}}
> -bash: ${OFFSET: bad substitution
>
> or:
>
> # declare -A A=([a:b]=0)
> # echo ${PARAM:${A[a:b]}}
> -bash: ${A[a: bad substitution
>
> It seems that the issue is in the use of skiparith in verify_substring_values. Switching to to skip_to_delim removes this issue. The ${parameter/pattern/string} expansion uses skip_to_delim to search for the second '/' so I suspect it's use is appropriate here as well.
It's not quite that simple. The reason skiparith() is used is that
arithmetic expressions may contain a colon (test?exp1:exp2), so skiparith
skips over one colon for each `?'. I will have to figure out a way to
continue to support this syntax for backwards compatibility and allow for
colons in other contexts.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next — Previous in thread | Find similar
Substring expansion error when offset contains a colon grishalevit@gmail.com - 2015-10-19 00:45 -0700 Re: Substring expansion error when offset contains a colon Chet Ramey <chet.ramey@case.edu> - 2015-10-26 09:19 -0400
csiph-web