bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33468: A bug with yes and --help


From: Assaf Gordon
Subject: bug#33468: A bug with yes and --help
Date: Tue, 19 Feb 2019 02:53:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Hello,

On 2019-02-19 1:24 a.m., Bernhard Voelker wrote:
On 2/18/19 11:20 AM, Assaf Gordon wrote:
[...] what do you think ?

To Eric's suggestion, I'd remove the RESET_OPTIND function argument,
because it's never used.

+1

Re. OPTIND: what about resetting the values of all involved externals
to their previous value?

+  int saved_optind = optind;
...
+  /* Restore previous values.  */
+  optind = saved_optind;


I believe restoring optind is incorrect here - did the tests pass
after this change ?

For example, I get the following:
---
$ ./src/dd --
./src/dd: unrecognized operand ‘--’
Try './src/dd --help' for more information.

$ ./src/nohup --
./src/nohup: ignoring input and appending output to 'nohup.out'
./src/nohup: failed to run command '--': No such file or directory

$ ./src/yes -- | head -n1
--

---

All these programs expect 'optind' to point to the first non-option
argument (because they all called "getopt_long" directly before your
patch, and parse_gnu_standard_options_only() now calls getopt_long()
for them, indirectly).

So restoring it to its initial value of 1 is going to confuse the
programs when they look into argv[optind] .

Unless I got confused (it's rather late here).
I'll double-check in the morning.

regards,
 - assaf










reply via email to

[Prev in Thread] Current Thread [Next in Thread]