git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] do not mangle short options which take arguments

From
Clemens Buchacher <drizzd@aon.at>
Date
Oct 2, 2009, 07:36 UTC
Message-ID
<20091002073628.GA9444@localhost>
In-Reply-To
<20091002061159.GA24892@coredump.intra.peff.net>
On Fri, Oct 02, 2009 at 02:11:59AM -0400, Jeff King wrote:
> I thought the proposal was to disallow just cuddling of the value when
> the switch was combined with others. So you would disallow "git commit
> -ammend" but it would still be legal to do "git commit -am foo". Your
> patch disallows the latter.

Yes, that syntax looks reasonable. I expect this to be more involved, so I will rework the patch once we agree on whether or not we want it at all.

Show 5 quoted lines
> To be honest, I am not sure that even the more restricted proposal is
> that good an idea. You are introducing a heuristic to guess at what is a
> typo or error from the user; when your guess is wrong, the user will be
> annoyed (doubly so if it is buried deep in a script, which this change
> will also impact).

Yes, that can happen. On the other hand, the "-ammend" typo actually did happen. And what I'm even more worried about are ambiguities like

  $ git commit -uno <path>
  $ git commit -nou <path>
which are interpreted as one of
  $ git commit --untracked-files=no <path>
  $ git commit --untracked-files --no-verify --only <path>

depending only on the order of the switches. I was actually surprised that I could find an example so easily. But the fact alone that it's possible feels like an accident waiting to happen.

> On the other hand, the cuddled value already has some DWYM magic (it
> recognizes -amend), so it is already a little bit unsafe to use

Well, an error message is a lot safer than executing something you did not intend.

Show 5 quoted lines
> So I don't feel _too_ strongly. I am just concerned that we are
> introducing some DWYM magic that is not really going to help many people
> out, and is just going to make understanding the rules for option
> parsing more complex, and introduce the possibility (albeit slim) of
> breaking people's scripts and trained fingers.

But it makes the rules simpler, because it removes ambiguities such as the one above.

Yes, we deliberately allow users to shoot themselves in the foot. But they should have to use at least a long option to do it.

Clemens
Previous: Jeff KingNext: Paolo Bonzini
Message 16 of 21 in “how optparse can go horribly wrong”
  1. Shawn O. PearceSep 25, 2009
  2. Nicolas SebrechtSep 26, 2009
  3. Sverre RabbelierSep 26, 2009
  4. Shawn O. PearceSep 26, 2009
  5. Clemens BuchacherSep 28, 2009
  6. 1/2 do not mangle short options which take argumentsClemens Buchacher, Oct 1, 2009
  7. 2/2 allow mangling short options which take integer argumentsClemens Buchacher, Oct 1, 2009
  8. Johannes SchindelinOct 1, 2009
  9. Clemens BuchacherOct 2, 2009
  10. Jeff KingOct 2, 2009
  11. Clemens BuchacherOct 2, 2009
  12. Johannes SchindelinOct 2, 2009
  13. Clemens BuchacherOct 3, 2009
  14. Johannes SchindelinOct 1, 2009
  15. Jeff KingOct 2, 2009
  16. Clemens BuchacherOct 2, 2009
  17. Paolo BonziniOct 2, 2009
  18. Jeff KingOct 2, 2009
  19. Johannes SchindelinOct 2, 2009
  20. Jeff KingOct 2, 2009
  21. Johannes SchindelinOct 2, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.