Command: Adding argument called 'command' makes other args/options unreadable about symfony

[flkasper]

Reproducible and should concern all versions.
But it's quite easy to explain. command is (currently) reserved for the internal command name.

In my opinion, the solution should be as @cavias has described.

In the simplest case, command is treated as a reserved name and an exception is thrown when an argument is added with it.

Of course, it would be nicer if you could also use command as the argument name.
Renaming the internal command name would be a breaking change and would not completely rule out further collisions.

A separation of argument and command name handling should be possible to a limited extent by taking the position into account during tokenizing (command name is always in the first position).
This would work in ArgvInput, but not for ArrayInput (used, for example, to call other commands).
There, the name of the command/argument/option is used as the key, example['command' => 'foo:bar', 'foo' => 'bar', '--bar' => 'foobar'].

[chalasr]

I would consider command a "reserved" argument name.
If we can do something to make it more explicit and ease understanding it, without breaking existing code (even if that code works by chance/luck), let's do it.

But to be honest, such edge cases exist for sure and we definitely don't want to break them, nor ask them to find another way to solve their need especially as it is likely to be more involving than just renaming command to something else in their application (thinking to OSS or proprietary tools using/extending/hacking the console, there's a lot).

That said, if you don't have a real use case I suggest not putting much effort into this and eventually close.

[cavias]

I would consider command a "reserved" argument name. If we can do something to make it more explicit and ease understanding it, without breaking existing code (even if that code works by chance/luck), let's do it.

But to be honest, such edge cases exist for sure and we definitely don't want to break them, nor ask them to find another way to solve their need especially as it is likely to be more involving than just renaming command to something else in their application (thinking to OSS or proprietary tools using/extending/hacking the console, there's a lot).

That said, if you don't have a real use case I suggest not putting much effort into this and eventually close.

I ran into this because I wanted to have an argument named "command" because of some custom usecase. But I just changed the argument into some other name as the name of the argument is arbitrary.

The main issue I had is that I spend an hour figuring out why my other arguments were failing to register for no obvious reason, only to find this bug.
And I imagine someone else will run into this as well in the future, which is why I recommend this is resolved somehow.