Thank you.

This looks super cool. =)

Thanks :)

I've updated this PR to complete most of the important TODO items (and also updated the usage in the PR description). It still needs more unit tests (I used a local shell script to test things, I need to convert it to unit tests) and I need to add a line to the CHANGELOG. Other than that, I think this in a final state, so ready for reviews :)

Should we target6.0 and mark this big new feature as@experimental?

My general opinion is that we mark too many classes experimental.

But I let@wouterj decide in this specific case.

The public API side of this feature is quite minimal (one method inConsole which needs full BC and 2 classes that we should mark as@final). The feature itself is purely DX (i.e. it's not that big of a deal if it stops working), so I agree with not marking this as experimental.

Adding support for ZSH might break things, but a community member already stepped up to provide a PR for this if this is merged, so this can be caught before the 5.4 release. Other than that, all complexity of this feature is in theCompletionInput::bind() method, which will all be normal "bug fixes".

I guess the lack of reviewers in this PR indicates that it's probably a bit difficult to review. Some hints:

• The main logic is inCompleteCommand andCompletionInput. The command receives an array of input "words" (similar to$argv) and the index in that array of the current cursor position (to know where completion is requested). Based on this,CompletionInput has to provide the correct type, value, option name, etc. That is the core logic of this PR (see also its tests).
• From a DX side, seeSecretsRemoveCommand::complete(),Command::complete() andApplication::complete() for PHP usage of this feature.
• If you're into bash, consider reviewingcompletion.bash andBashCompletionOutput. That latter is not doing much (only providing completion options as space-separated values). The first one is a bit more complex than the basic bash completion function, in order to simplify working with colons in the command names and= signs in between option name and value.

@wouterj I'm looking for a simple way to test this in my actual app, IMO it would be most beneficial to figure it all out. I'll provide my findings if I find a way to do that.

Other than that, a cool sample might be to make a fork of Composer with this enabled. It might make it simple to visualize once you can test it for yourself easily.

Also, this is an absurdly valuable feature, thank you a lot for working on this! 😍

@dkarlovi if you have an app running Symfony 5.3, you can try to clone my fork locally and use thelink utility:

git clone https://github.com/wouterj/symfony -b issue-38275/shell-autocompletecd symfony./link /path/to/project

And then use theeval $(bin/console completion bash) in your app.

@wouterj which Bash did you use to test this? For me, if I test withbin/console, it doesn't work, but./console works, but need to change CWD obviously.

To get it to work, I needed to change it like this:

complete -F _sf_console bin/console

Also, theeval trick you gave didn't register the completion for me (checked withcomplete -p console), had to pipe it to a file and source it

bin/console completion bash > foo.shsource foo.sh

One thing which might be neat to have is to provide a flag for the dumper, something like

bin/console completion bash --verbose-completion

or similar, where it would create additional code in there to help you debug it if you're working on it. Might be too niche, maybe wait for use cases, but as I was testing this, I needed to edit the completion function to add them myself.

Thanks for the review@theofidry!

PR updated and rebased. We have a new failure (7.2) but I can't find any error logs whatsoever about this failure.

Thanks, PR updated.

Thank you@wouterj.