Bug 498585

Description of problem:
Variable expansion differs between two release of ksh shell.

How reproducible:
It is reproduciable.
With ksh Version : 20060214 Release : 1.7 and Version : 20080202 Release : 2.el5, below mentioned script result differs.
------script----------
#!/bin/ksh 
set -x 
set -v 
 
cmdname=nastran 
prod=md2008 
echo $prod[1-9][0-9]* 
 
[[ $cmdname = $prod[1-9][0-9]* ]] && echo cond1 is true || echo cond1 is false
------script----------


Steps to Reproduce:
Execute below sample script on mentinoed ksh versions, output will be different. expanssion of $prod[1-9][0-9]* is different and so the result.
------script----------
#!/bin/ksh 
set -x 
set -v 
 
cmdname=nastran 
prod=md2008 
echo $prod[1-9][0-9]* 
 
[[ $cmdname = $prod[1-9][0-9]* ]] && echo cond1 is true || echo cond1 is false
------script----------

Actual results:
Expansion of " $prod[1-9][0-9]* " differs between mentioned two version of ksh.
On ksh Version : 20060214 Release : 1.7 it expands to : md2008[1-9][0-9]*
On ksh Version : 20080202 Release : 2.el5 it expands to : *

Expected results:
Customer want to get the same output for expansion of " $prod[1-9][0-9]* " i.e. md2008[1-9][0-9]*

Additional info:
If we use ${prod}[1-9][0-9]* instead of $prod[1-9][0-9]* then result is same on both the mentinoed version ksh.

Customer is having tons of ksh script , he is not willing to change all these scripts. And also mentioned that if it is available in previouse version then it should be there in latest/next release.
This event sent from IssueTracker by mpoole  [Support Engineering Group]
 issue 291398

The problem they are seeing is a result of the following change that was
made between the two versions.

07-06-18  The braces for a subscripted variable with ${var[sub]} are now
	  optional when inside [[...]], ((...)) or as a subscript.


It would appear that this was conditionally reverted later which appears
to cover their use case

08-03-03  The change made in ksh93s+ on 07-06-18 in which braces became
	  optional for ${a[i]} inside  [[...]] was restored in the case
	  where the argument can be a pattern.


I will create a BZ regarding this. Engineering will decide on the
feasibility of fix.

Customer should be made aware that their scripts may still be liable to
failure whilst they insist on not enclosing variables in {} as defined in
the documentation.  There are exceptions, but the presence of indexed and
associative arrays within the ksh functionality means that consistent
interpretation cannot be guaranteed unless they follow the stricter
requirements.


This event sent from IssueTracker by mpoole  [Support Engineering Group]
 issue 291398

It's difficult to locate changes in ksh sources, because there is no repository, but I was able to find some change matching your reproducer. (07-06-18 change is not reverted, only braces for pattern are not optional). Attached patch should do this, feel free to test if this is all you need.

Created attachment 342617 [details]
patch taken from upstream 2008-07-25

I was able to reproduce this bug. Ksh with this patch gives old behaviour for reproducer.

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
In the last version of ksh, braces for a subscripted variable with ${var[sub]} became compulsory when inside [[...]], ((...)) or as a subscript. Because these braces were previouly optional, some shell scripts written for earlier versions of ksh no longer worked as expected. Ksh now recognises cases where the argument can be a pattern, and expands these variables the same way that it expanded them when the braces were optional. While this allows many old scripts to work in the current version of ksh, users cannot be certain that their scripts will work as expected unless they enclose variables in braces as defined in the ksh documentation.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1256.html