Red Hat Bugzilla – Bug 431005
parse_long_options doesn't respect "--"
Last modified: 2010-02-22 07:35:52 EST
Description of problem: I think that parse_long_options() in long-options.c is broken in a few very minor ways. There appears to be no way for echo to print out the string "-n" or "--help" or the other things that happen to be options because it doesn't respect "--" like most other things do. The fact that parse_long_options() looks at argc when deciding whether to parse options is also kind of strange and leads to this funny error: % sleep --help --version sleep: unrecognized option `--help' Try `sleep --help' for more information. The fact that I can't get yes to repeatedly print out "--help" is odd but not a huge issue. The fact that echo can't print out a literal "-n" seems like it might be a (minor) problem, though. Version-Release number of selected component (if applicable): GNU coreutils 5.2.1 The unnecessary argc check seems to still be in the source code for coreutils 6.10. How reproducible: Always reproducible via "sleep --help --version" or "echo -- -n" Actual results: "echo -- -n" prints out "-- -n" instead of "-n" Expected results: "-n"
Fixed and built as coreutils-6.10-4.fc9 in fedora RAWHIDE branch.
Well, echo change was not accepted by upstream (as not justified and potentially breaking scripts), so I will remove that functionality from Fedora in next coreutils builds. In fact you could use POSIXLY_CORRECT env.variable or printf command for such things. POSIX says do not use any options in echo. So that one part is NOTABUG (full thread on upstream mailing list is http://lists.gnu.org/archive/html/bug-coreutils/2008-03/msg00111.html)...
Thanks for reverting this. This did break scripts, at least for me. The only reason I knew this was changed was from the RPM changelog. I didn't see any mention of you reverting this in the changelog, but my scripts work now.