Bug 858397 - getopt fails to fully extract parameter string
getopt fails to fully extract parameter string
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc4 (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 17:08 EDT by Leslie Satenstein
Modified: 2012-09-18 18:12 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-18 18:12:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leslie Satenstein 2012-09-18 17:08:10 EDT
Description of problem:

64 BIT compiler
version gcc 4.7 ond glibc as of 18sept 2012 (most current non Rawhide)
getopt fails to extract complete string. It is should not be context sensitive

Version-Release number of selected component (if applicable):
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)


How reproducible:

see below
in my command line, I have setup different tests as myprog -k xxxxxxxxxxx   
                 
getopt retrieves only the integer 1 and does not return [1,2] << error
if I change the format to -k "[1,2]"  I retrieve [1,2]   << no error
if I change the format to -k[1,2]     i retrieve [1,2]   << no error

If instead of -k [1,2] I have -k [x,y] with x != 1   getopt works <<no error

here is the code fragment

 while ((c = getopt (argc, argv, "bd:e:f:hi:k:pr:tuv")) != (-1))
    {
      switch (c)
	{
    	case 'b':  cbc = 0;	  			break;
    	case 'f':  setflag(fflag); tablename=optarg;    break;
	case 'e':  encrypt=1; infile=optarg;		break;
	case 'd':  decrypt=1; infile=optarg;		break;
	case 'h':  setflag(hflag);			break;
        case 'i':  ipath=optarg; setflag(iflag);        break;
	case 'k':  setflag(kflag); tkey1=optarg;  	break;
      	case 'p':  setflag(pflag);			break;
        case 'r':  setflag(rflag); opath=optarg;	break;
	case 't':  setflag(tflag); start_clock();     	break;
	case 'u':  setflag(uflag);			break;
	case 'v':  verbose++;	  			break;
        default : setflag(hflag);         		break;
	}
    }

Steps to Reproduce:
1.   myprogram -e file1 -k [1,4]       fails
2. 
3.   myprogram -e file1 -k [2,4]       works   
  
Actual results:

This was working with gcc before 4.7 

Expected results:

-k [1,2] must return [1,2]

Additional info:

I am gluing the parameter with the -k as -k[1,2] or using it as -k "[1,2]"

I can walk through and test source of getopt to provide correct version
Comment 1 Jakub Jelinek 2012-09-18 17:25:08 EDT
This has nothing to do with gcc (getopt is a library function in glibc), but I'd guess that you have simply a file called 1 in the current directory, therefore
[1,4] is expanded as 1 already by the shell ([1,4] stands for 1, or comma, or 4).
Comment 2 Leslie Satenstein 2012-09-18 18:01:44 EDT
Is bash treating [1,3] as a regular expression? If so, why does 
[15.0] work, but not [14,15]
Comment 3 Leslie Satenstein 2012-09-18 18:08:13 EDT
WRONG.  There is no file in the current directory with the number 1.
al files are *.h *.c makefile and *.sh

Either bash is doing something to my  -k xxxx  where xxx is bounded by [] as matching braces or matching {}.

or there is a bug with getopt.  

My file that I am testing with is alphanumeric in name as bigfileX where the output is a transformation to another file.

The -k [x,y] is selective. Before you close this as not a bug, I will do some bash testing to determine its role. 

In the interrim, I have put my parameters within single quotes.
Comment 4 Leslie Satenstein 2012-09-18 18:12:03 EDT
Please close getopt bug.   It is bash causing command line interference,

Sorry to raise false alarm.

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