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

[cavias]

Symfony version(s) affected

7.0.6

Description

Adding an argument called "command" to a custom Symfony command seems to conflict with the internal "command" value, making other parameters inaccessible.

There should probably be some filter/fix for this.

How to reproduce

Step 1: Create the following Command (Just add your own namespacing and such):

#[AsCommand(
    name: 'some:command',
    description: 'Some command doing something.',
)]
class SomeCommand extends Command
{
    protected function configure(): void
    {
        $this
            // The issue seems to be adding an argument called "command"
            ->addArgument('command', InputArgument::REQUIRED)
            ->addArgument('action', InputArgument::REQUIRED)
            ->addOption('cavia', 'c', InputOption::VALUE_REQUIRED, 'Cavialiefde');
    }

     public function run(InputInterface $input, OutputInterface $output): int
     {
         // This is fine and returns "some:command"
         $command = $input->getArgument('command');

         // This fails with InvalidArgumentException "The "action" argument does not exist."
         // Even though it is clearly registered.
         $action = $input->getArgument('action');

         // This also fails with InvalidArgumentException "The "cavia" option does not exist."
         // Even though it is clearly registered.
         $cavia = $input->getOption('cavia');

         return Command::SUCCESS;
     }
}

Step 2: Run php bin/console some:command whatever thing --cavia=cavia

Possible Solution

In my opinion I should be able to get the 'command' argument as well as the other registered arguments and options.
Or the 'command' should be illegal as custom argument name and produce an Exception for that.
Or the argument 'command' should be handled separately from the internal commandname.

Additional Context

Note: I don't have a usecase for this. I just came across this while testing.

[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.