Bug 1222025

Summary: unset arguments are not treated as an error when set -u is used
Product: Red Hat Enterprise Linux 7 Reporter: Marcel Kolaja <mkolaja>
Component: kshAssignee: Siteshwar Vashisht <svashisht>
Status: CLOSED ERRATA QA Contact: Jan Kepler <jkejda>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: fkrska, isenfeld, jkejda, kabbott, kdudka, mhlavink, rpiddapa, svashisht, zpytela
Target Milestone: rcKeywords: Patch, Reopened, Reproducer
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: ksh-20120801-34.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1466395 (view as bug list) Environment:
Last Closed: 2017-08-01 16:26:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1298243    
Attachments:
Description Flags
reproducer none

Description Marcel Kolaja 2015-05-15 14:11:04 UTC 
Description of problem:
When set -u is used, ksh should treat unset parameters as an error when substituting. This does not work for unset positional parameters like $1. It does work, however, for usual variables (see the attached reproducer).

Version-Release number of selected component (if applicable):
20120801-22.el7_1.1

How reproducible:
always

Steps to Reproduce:
1. run the attached reproducer

Actual results:
No error printed for $1.

Expected results:
An error printed for $1

Additional info:
N/A
Comment 1 Marcel Kolaja 2015-05-15 14:11:43 UTC 
Created attachment 1025897 [details]
reproducer
Comment 4 Michal Hlavinka 2015-05-17 20:51:52 UTC 
This is intentional change made by upstream.
09-05-12  To conform with POSIX, the -u option only checks for unset variables
	  and subscript elements rather than checking for all parameters.
Comment 5 Karl Abbott 2015-05-19 11:53:51 UTC 
Michal,

Had the customer ask the following:

"Your update is clear that upstream made this as a deliberate change to conform with POSIX.

Is the upstream position that this is not a bug/ regression and will not be fixed and that the previous behaviour will not be made available through an option/ environment variable?

Tim
"

I re-opened this so that you'll get the notification. I would like to have an answer to this as I think it's a really well thought out question.

Cheers,
Karl
Comment 6 Karl Abbott 2015-05-20 16:42:41 UTC 
Michal,

Also:

"Hi Karl,

A point of interest:

Checking with our Solaris team they have a case open with Oracle for the same issue.

Oracle responded to our Solaris team today that they (Oracle Solaris engineering) have been working on a change which has been integrated into the upstream.

Tim"

Karl
Comment 11 Marcel Kolaja 2015-09-17 16:00:11 UTC 
When the change in varsub() in macro.c mentioned in the following post is made, we get in the newly added part of the code, when $1 is being expanded:

http://lists.research.att.com/pipermail/ast-developers/2015q2/004038.html

Then strchr() seems to return a pointer to the terminator and errormsg() is not called.
Comment 19 Siteshwar Vashisht 2017-01-30 13:20:05 UTC 
Upstream patch is slightly different from the submitted patch in comment 12, check for non-zero d is unnecessary :


https://github.com/att/ast/blob/beta/src/cmd/ksh93/sh/macro.c#L1230-L1236

if(!v && sh_isoption(mp->shp,SH_NOUNSET))
	{
         d=fcget();
         fcseek(-1);
         if(!strchr(":+-?=",d))
	     errormsg(SH_DICT,ERROR_exit(1),e_notset,ltos(c));
	}
Comment 20 Siteshwar Vashisht 2017-01-30 16:06:15 UTC 
strchr() can search for NULL characters in string, so check for 0 is required. The patch in comment 12 looks good.
Comment 24 errata-xmlrpc 2017-08-01 16:26:55 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1936