Update args.go

[smzelek]

Call function on properly on iterator variable

[smzelek]

hi. I just noticed while looking thru the source code for this function that it iterates over a list of args[] with an iterator variable v but calls a function that always references args[0] in the error call.

[marckhouzam]

Thanks for helping out @smzelek ! If you notice, the arg[0] is used because we want to output the command name for which the different v arguments are given. So the command is always located at arg[0].

Makes sense?

[CLAassistant]

All committers have signed the CLA.

[smzelek]

hi @marckhouzam, I'm not sure that is correct.

I have provided a minimum repro to facilitate easier communication in case either of us are misunderstanding something.

https://github.com/smzelek/cobra-1721-repro

[marckhouzam]

Hi @smzelek and sorry for the delay. This seems to be a tricky one. I believe you are right that the proper argument should be v as your PR modifies.

However, after digging deeper, I think there is no impact to that change. From what I can see, suggestions are only made for mistyped sub-commands. That is why you had to make level-3 a sub-command in your example. There are no suggestions for mistyped arguments that are not sub-commands.

But a sub-command can only be the first argument of its parent command, so the argument for which we can make a suggestion will always be at args[0]. So effectively, when it matters, args[0] == v. Do you agree?

Do you see any mis-behaviour at any time? Maybe I missed a possible scenario. That being said I agree that it reads quite poorly and could possible prove buggy in the future.

I would feel more justified changing the code if you actually had a situation that was not behaving as it should, so if you have one, please let me know.

[github-actions[bot]]

The Cobra project currently lacks enough contributors to adequately respond to all PRs. This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the PR is closed. You can:
• Make a comment to remove the stale label and show your support. The 60 days reset. - If a PR has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening.