Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: Substring expansion error when offset contains a colon Date: Mon, 26 Oct 2015 09:19:09 -0400 Organization: ITS, Case Western Reserve University Lines: 28 Approved: bug-bash@gnu.org Message-ID: References: Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1445865588 2415 208.118.235.17 (26 Oct 2015 13:19:48 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: grishalevit@gmail.com, bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.562E2868.00D6,ss=1,re=0.000,fgs=0, ip=149.160.129.54, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: 872189091c66ca5b7074179bf03f1d01 X-Junkmail-Whitelist: YES (by domain whitelist at mpv1-2015.case.edu) X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.562E286B.01F1,ss=1,re=0.000,fgs=0, ip=149.160.129.54, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: 8d488f0fcbeec3e50c39aba98e5e38be X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.226 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11768 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/