Bug 858397
| Summary: | getopt fails to fully extract parameter string | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Leslie Satenstein <lsatenstein> |
| Component: | gcc4 | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-09-18 22:12:03 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: | |||
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). Is bash treating [1,3] as a regular expression? If so, why does [15.0] work, but not [14,15] 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.
Please close getopt bug. It is bash causing command line interference, Sorry to raise false alarm. |
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