Bug 498585 - ksh shell variable expansion in conditional expressions
ksh shell variable expansion in conditional expressions
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ksh (Show other bugs)
5.3
All Linux
high Severity high
: rc
: ---
Assigned To: Michal Hlavinka
BaseOS QE
: Regression
Depends On:
Blocks: 499522
  Show dependency treegraph
 
Reported: 2009-05-01 06:35 EDT by Issue Tracker
Modified: 2010-10-23 05:19 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:11:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch taken from upstream 2008-07-25 (448 bytes, patch)
2009-05-06 05:06 EDT, Michal Hlavinka
no flags Details | Diff

  None (edit)
Description Issue Tracker 2009-05-01 06:35:45 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2009-05-01 06:35:47 EDT
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
Comment 2 Issue Tracker 2009-05-01 06:35:49 EDT
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
Comment 3 Michal Hlavinka 2009-05-06 05:05:22 EDT
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.
Comment 4 Michal Hlavinka 2009-05-06 05:06:27 EDT
Created attachment 342617 [details]
patch taken from upstream 2008-07-25
Comment 5 Michal Hlavinka 2009-05-06 05:08:13 EDT
I was able to reproduce this bug. Ksh with this patch gives old behaviour for reproducer.
Comment 9 Ruediger Landmann 2009-05-19 00:04:13 EDT
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.
Comment 24 errata-xmlrpc 2009-09-02 05:11:21 EDT
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

Note You need to log in before you can comment on or make changes to this bug.