I'm trying to write fish-shell completions for eselect but the PHP is giving me a hard time making the parsing generic. The PHP eselect module is the only module that works like this: eselect <module> <action> <submodule> (<target>) every other one uses: eselect <module> <action> (<target>) The submodules are not even supplied in an easily parsable format. This would make parsing of the usage text php specific, this is not what I would like. I see two different approaches for making this eselect better parsable. 1. Split the module into the modules: php-cli, php-apace2, php-fpm, and php-cgi This would make the completions work right out of the box. 2. List the submodules in a more accessible way: like a list-modules action that would output the different modules with a small description. This would require some more work from me, but it would be generic and would automatically work when a module gets added or removed. Reproducible: Always Steps to Reproduce: 1. run: eselect php list 2. run: eselect python list Actual Results: For step one you will get an error an for step two you will get the available targets Expected Results: It shouldn't work like this.
I have the feeling this is not going to be fixed/changed any time in the foreseeable future.
(In reply to Jelte Fennema from comment #1) > I have the feeling this is not going to be fixed/changed any time in the > foreseeable future. We can't really make it work exactly like all of the other eselect modules, since we're able to set the CLI PHP different from e.g. the apache2 PHP. So we need that "cli" or "apache2" somewhere in the eselect command. I always forget how to invoke it, too. I did give you list-modules though: $ sudo eselect php list-modules cli apache2 fpm cgi phpdbg That should be in the latest eselect-php-0.9.1 that I just pushed. It's masked for testing, but please give it a try.
> (In reply to Michael Orlitzky from comment #2) > I did give you list-modules though: > > $ sudo eselect php list-modules > cli apache2 fpm cgi phpdbg > > That should be in the latest eselect-php-0.9.1 that I just pushed. It's > masked for testing, but please give it a try. Testing this at the moment, list-modules seems to work, but not entierly as one could expect since it also lists modules not installed/built. For example, I only have php built with CLI, and still get all the modules. But this is good enough for us to write dynamic completions, which is beeing done at the moment. But it would be even better if it didn't print modules that can't be used for one reason or another. If there's no selection available, is that module available then? In current build it is. But the new completions will depend on list-modules because it's good enough.
(In reply to Elis Axelsson from comment #3) > > (In reply to Michael Orlitzky from comment #2) > > I did give you list-modules though: > > > > $ sudo eselect php list-modules > > cli apache2 fpm cgi phpdbg > > > > That should be in the latest eselect-php-0.9.1 that I just pushed. It's > > masked for testing, but please give it a try. > > Testing this at the moment, list-modules seems to work, but not entierly as > one could expect since it also lists modules not installed/built. > > For example, I only have php built with CLI, and still get all the modules. > Yeah, they're all still valid arguments to `eselect php <action>` though, so they should show up in the tab-completion as long as we accept them. Useless, but valid: $ sudo eselect php list phpdbg (none found) And there are invalid arguments, so there is a distinction: $ sudo eselect php list derp !!! Error: Please choose one of the following modules: cli apache2 fpm cgi phpdbg exiting Maybe it would be nicer to throw an error if there are no targets -- that would let us trim the list of valid SAPIs -- but it's probably too late in the game to mess with the API without a good reason.
I'm going to resolve this because I think I've done as much as I can without breaking our API. If you need anything else, please don't hesitate to open a new bug.
