wp-cli / wp-cli

⚙️ WP-CLI framework

WP-CLI

WP-CLI is the command-line interface for WordPress. You can update plugins, configure multisite installations and much more, without using a web browser.

Ongoing maintenance is made possible by:

The current stable release is version 2.10.0. For announcements, follow @wpcli on Twitter or sign up for email updates. Check out the roadmap for an overview of what's planned for upcoming releases.

Quick links: Using | Installing | Support | Extending | Contributing | Credits

Using

WP-CLI provides a command-line interface for many actions you might perform in the WordPress admin. For instance, wp plugin install --activate (doc) lets you install and activate a WordPress plugin:

$ wp plugin install user-switching --activate
Installing User Switching (1.0.9)
Downloading installation package from https://downloads.wordpress.org/plugin/user-switching.1.0.9.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'user-switching'...
Plugin 'user-switching' activated.
Success: Installed 1 of 1 plugins.

WP-CLI also includes commands for many things you can't do in the WordPress admin. For example, wp transient delete --all (doc) lets you delete one or all transients:

$ wp transient delete --all
Success: 34 transients deleted from the database.

For a more complete introduction to using WP-CLI, read the Quick Start guide. Or, catch up with shell friends to learn about helpful command line utilities.

Already feel comfortable with the basics? Jump into the complete list of commands for detailed information on managing themes and plugins, importing and exporting data, performing database search-replace operations and more.

Installing

Downloading the Phar file is our recommended installation method for most users. Should you need, see also our documentation on alternative installation methods (Composer, Homebrew, Docker).

Before installing WP-CLI, please make sure your environment meets the minimum requirements:

• UNIX-like environment (OS X, Linux, FreeBSD, Cygwin); limited support in Windows environment
• PHP 5.6 or later
• WordPress 3.7 or later. Versions older than the latest WordPress release may have degraded functionality

Once you've verified requirements, download the wp-cli.phar file using wget or curl:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Next, check the Phar file to verify that it's working:

php wp-cli.phar --info

To use WP-CLI from the command line by typing wp, make the file executable and move it to somewhere in your PATH. For example:

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

If WP-CLI was installed successfully, you should see something like this when you run wp --info:

$ wp --info
OS:     Linux 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64
Shell:  /usr/bin/zsh
PHP binary:     /usr/bin/php8.1
PHP version:    8.1.0
php.ini used:   /etc/php/8.1/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
SQL modes:
WP-CLI root dir:        /home/wp-cli/
WP-CLI vendor dir:      /home/wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir:    /home/wp-cli/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:  /home/wp-cli/wp-cli.yml
WP-CLI version: 2.10.0

Updating

You can update WP-CLI with wp cli update (doc), or by repeating the installation steps.

If WP-CLI is owned by root or another system user, you'll need to run sudo wp cli update.

Want to live life on the edge? Run wp cli update --nightly to use the latest nightly build of WP-CLI. The nightly build is more or less stable enough for you to use in your development environment, and always includes the latest and greatest WP-CLI features.

Tab completions

WP-CLI also comes with a tab completion script for Bash and ZSH. Just download wp-completion.bash and source it from ~/.bash_profile:

source /FULL/PATH/TO/wp-completion.bash

Don't forget to run source ~/.bash_profile afterwards.

If using zsh for your shell, you may need to load and start bashcompinit before sourcing. Put the following in your .zshrc:

autoload bashcompinit
bashcompinit
source /FULL/PATH/TO/wp-completion.bash

Support

WP-CLI's maintainers and contributors have limited availability to address general support questions. The current version of WP-CLI is the only officially supported version.

When looking for support, please first search for your question in these venues:

• Common issues and their fixes
• WP-CLI handbook
• Open or closed issues in the WP-CLI GitHub organization
• Threads tagged 'WP-CLI' in the WordPress.org support forum
• Questions tagged 'WP-CLI' in the WordPress StackExchange

If you didn't find an answer in one of the venues above, you can:

• Join the #cli channel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
• Post a new thread in the WordPress.org support forum and tag it 'WP-CLI' so it's seen by the community.

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Before submitting a bug report, please review our best practices to help ensure your issue is addressed in a timely manner.

Please do not ask support questions on Twitter. Twitter isn't an acceptable venue for support because: 1) it's hard to hold conversations in under 280 characters, and 2) Twitter isn't a place where someone with your same question can search for an answer in a prior conversation.

Remember, libre != gratis; the open source license grants you the freedom to use and modify, but not commitments of other people's time. Please be respectful, and set your expectations accordingly.

Extending

A command is the atomic unit of WP-CLI functionality. wp plugin install (doc) is one command. wp plugin activate (doc) is another.

WP-CLI supports registering any callable class, function, or closure as a command. It reads usage details from the callback's PHPdoc. WP_CLI::add_command() (doc) is used for both internal and third-party command registration.

/**
 * Delete an option from the database.
 *
 * Returns an error if the option didn't exist.
 *
 * ## OPTIONS
 *
 * <key>
 * : Key for the option.
 *
 * ## EXAMPLES
 *
 *     $ wp option delete my_option
 *     Success: Deleted 'my_option' option.
 */
$delete_option_cmd = function( $args ) {
	list( $key ) = $args;

	if ( ! delete_option( $key ) ) {
		WP_CLI::error( "Could not delete '$key' option. Does it exist?" );
	} else {
		WP_CLI::success( "Deleted '$key' option." );
	}
};
WP_CLI::add_command( 'option delete', $delete_option_cmd );

WP-CLI comes with dozens of commands. It's easier than it looks to create a custom WP-CLI command. Read the commands cookbook to learn more. Browse the internal API docs to discover a variety of helpful functions you can use in your custom WP-CLI command.

Contributing

We appreciate you taking the initiative to contribute to WP-CLI. It’s because of you, and the community around you, that WP-CLI is such a great project.

Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Read through our contributing guidelines in the handbook for a thorough introduction to how you can get involved. Following these guidelines helps to communicate that you respect the time of other contributors on the project. In turn, they’ll do their best to reciprocate that respect when working with you, across timezones and around the world.

Leadership

WP-CLI has one project maintainer: schlessera.

On occasion, we grant write access to contributors who have demonstrated, over a period of time, that they are capable and invested in moving the project forward.

Read the governance document in the handbook for more operational details about the project.

Credits

Besides the libraries defined in composer.json, we have used code or ideas from the following projects:

• Drush for... a lot of things
• wpshell for wp shell
• Regenerate Thumbnails for wp media regenerate
• Search-Replace-DB for wp search-replace
• WordPress-CLI-Exporter for wp export
• WordPress-CLI-Importer for wp import
• wordpress-plugin-tests for wp scaffold plugin-tests

wp-cli's Issues

Coding standards

The current code is very clean and easy to read, but it will get messier once more than one person is involved.

As such, I propose we adopt the WordPress Coding standards, so that everyone is on the same page.

This doesn't mean that you would have to go and add extra spaces around every function calls etc. just that this should be the formatting of new code added.

I think cleaning up one file at a time, as it's being worked on, is a good way to go about it. I say one file because the spaces have to be converted to tabs and it's not good to have both types of indentation in the same file.

issue with wp-content in a separate directory

I'm having trouble getting this to work with wp-content in a separate directory. When I do 'wp plugin status' I don't see any of my plugins. I tried adding a symlink to the directory but that didn't fix it either.

XML-RPC commands

Any chance of including an XML-RPC client with this script, or are you focusing on local WP instances only?

mac os x installation, can't access mysql.sock

after executing wp in wordpress directory:

Warning: mysql_connect(): [2002] No such file or directory (trying to connect via unix:///var/mysql/mysql.sock) in ~/Sites/wp/wp-includes/wp-db.php on line 1034

my mysqlsock is located in /tmp/mysql.sock

I run mysqld on-demand - open shell and run it for development, it is not always loaded

runing configuration is nginx-1.0.10/php-fpm-5.3.6/mysql-5.5.15

Add import/export commands

Tott has written some neat utilities for importing and exporting posts via cli:

https://github.com/tott/WordPress-CLI-Importer

https://github.com/tott/WordPress-CLI-Exporter

It makes sense to bring them into wp-cli, to avoid all the duplicated code related to loading WP, parsing arguments etc.

I guess it would be best if they were separate, top-level commands:

wp import --file=...

wp export ...

--silent global flag

Basically, it would suppress WP_CLI::success() messages and any other non-error output.

Make packages for apt-get, homebrew etc.

Related: #3

wp core update reports success, yet does nothing

wp core update command reports success, yet core update doesn't happen. This is supposed to work, right?

$ wp core version --extra
WordPress version:  3.1.3

Database revision:  17516
TinyMCE version:    3393a
Manifest revision:  20111113

$ wp core update
Updating the WordPress core.
Success: WordPress is at the latest version.

$ wp --version
wp-cli 0.4.0-dev

Bash completions

I don't know if in OS X it's the same, but in Ubuntu you can write a script that generates completions for a certain command.

So, for example, if you write wp p and press TAB, you will automatically get wp plugin.

Stop using php-cli-tools

Reasons:

• it requires PHP 5.3, which is not widely available on production servers (#59)
• we don't use any of it's advanced features, such as menus and progress indicators
• it's not actively developed (last commit was in July, 2010)

db-migrate command

My fork's code is largely baked -- at least well enough to start discussing its integration.

While it's currently positioned as a community command in the code base, I think it really should be an internal command. I've added it here: https://github.com/andreascreten/wp-cli/wiki/List-of-internal-commands for that reason, and because the table better fits the scope of the feature versus the tables on the community command page.

`wp plugin install <name> --activate`

On a non-multisite install, you usually want to activate the plugin you just installed.

Similar to git submodule update --init.

`wp plugin path`

wp plugin path [<plugin-name>] [--directory] would print the path to the plugins directory or to the main file (or directory) of a specific plugin.

MAMP Support?

I tried this out in a MAMP environment and received a #2002 MySQL error.

Traced it to the fact the MAMP php.ini was not being loaded, therefore the ini setting for mysql.default_socket is set to "/var/mysql/mysql.sock", not "/Applications/MAMP/tmp/mysql/mysql.sock".

Thoughts on support for MAMP? Not sure how MAMP detection might work, we'd have to also detect which version of MAMP the user is running and load the appropriate php.ini file.

Improve bootstrap for multisite

On a multisite install, if you forget to pass the --blog parameter, you get some warnings. If you pass an invalid value, you get nothing at all.

You should be able to just call wp and have it run as the main blog.

This will likely require some ingenuity with regards to the bootstrap process.

--url global parameter

When doing automated integration testing, it would be useful to test different contexts: single posts, tag archives etc.

The easiest way to do this would be by passing a --url=http://my-blog.com/tag/foo, which would supersede the --blog parameter.

Make `wp plugins status` list all plugins

It would be nice if typing ./wp plugins status would output the list of plugins, along with their status, kind of like how git status works:

 A  akismet.php
 I  hello-dolly.php

where 'A' stands for active, 'I' for inactive. There would also be 'NA' for network activated, 'MU' for must-use etc.

Color coding would also be cool. :)

`wp plugin status <slug>` should be more descriptive

Currently, it looks like this:

$ wp plugin status example

Plugin example details:
    Active: 1
    Version: 0.9.2-alpha

Proposed:

$ wp plugin status example

Plugin example details:
    Status: Must Use
    Version: 0.9.2-alpha

where Must Use is colored, similarly to when doing wp plugin status

Additionally, all the other fields could be displayed: Author, Description etc.

Add a more unix friendly output format for wp option get

wp-cli looks fantastic, and it looks like it'll make automating wordpress deployments much easier, but adding an easier to grep format option like how drush does for drupal would make the tool much more powerful, and easier to work with, when scripting.

Look at the syntax for drush:

variable-get
Lists the variables for your site

Examples:
 drush vget           List all variables and values.    
 drush vget user      List all variables beginning with 
                      the string "user".                


Arguments:
 name                 A string to filter the variables by. 
                      Only variables beginning with the
                      string will be listed.


Options:
 --pipe               Use var_export() to emit executable 
                      PHP. Useful for pasting into code.  

This doesn't look like a huge change to make this work, mostly around changing the options.php file in wp-cli/commands/internals to export vars instead.

Possible?

`wp core install` command

It would fetch the zip from wordpress.org, extract it, create a wp-config.php file and then load wp-admin/install.php I guess.

It would look like this (arguments in brackets are optional):

wp core install
  --blog=newsite.com [email protected]
  --db-name=wordpress --db-user=root --db-pass=somePassw0rd [--db-host=localhost]

NB: I don't plan on working on this; just wanted to have a place for discussing it.

man pages?

The current help methods are nice for a quick overview of a command, but manual pages would allow more thorough explanations.

Or we could have a wp wiki <command> command which would open the appropriate wiki page in a browser. The problem with using the wiki for documentation is that it can get out of sync: wp-cli 0.5 might have very different commands from wp-cli 0.2.

Loop through all blogs

Theoretically, all commands could be run on each blog in a multisite install.

It should also work with multi-network installs.

Possible syntaxes:

• wp --network=<network-path> post generate
• wp blog foreach post generate (similar to git submodule foreach)

See the wp_site table for reference.

Default subcommands

Currently, when you write wp plugin it show you the help.

It would be nice if it showed you the plugin status instead.

Even nicer would be if you could easily choose what the default subcommand was, without overwriting the constructor.

Commit incoming.

Installation via git fails on OSX Lion.

When installing via

git clone --recurse-submodules git://github.com/andreascreten/wp-cli.git ~/git/wp-cli
cd ~/git/wp-cli
sudo utils/build-dev

on OSX Lion I run into some errors due to missing directories. The following changes to build-dev solve the issue for me

#!/usr/bin/env bash

if [ ! -L /usr/bin/wp ]; then
        ln -s $(pwd)/src/bin/wp /usr/bin/wp
fi

if [ ! -d /etc/bash_completion.d/ ]; then
        mkdir /etc/bash_completion.d
fi
if [ ! -L /etc/bash_completion.d/wp ]; then
        ln -s $(pwd)/utils/wp-completion.bash /etc/bash_completion.d/wp
fi

wp sql

I'm working in wp sql command. I want to implement the following options based on Drush. I've already have a basic implementation of cli and connect commad.

• cli Open a SQL command-line interface using Wordpress's credentials.
• connect A string for connecting to the DB.
• dump Exports the wordpress DB as SQL using mysqldump or equivalent.
• query Execute a query against the site database.

https://github.com/matiskay/wp-cli/blob/master/commands/community/sql.php

no output, probably doesn't do anything either

I'm using this on an Ubuntu 11.10 server, installed via git clone and with the latest WP install. When I type "wp" in the console in side a wp install directory, I get no output for most commands. Things like --version work, but that's about it. Seems like there is an unhandled error or something, because it just returns with no output.

It might be a problem with memory limits, maybe? Although it outputs no errors...

'wp home' doesn't work

On Ubuntu, I get this error:

Couldn't get a file descriptor referring to the console

Strangely enough, I also get the success message afterwards:

Success: The wp-cli homepage should be opening in your browser.

but nothing happens.

theme install and update commands

Just noticed we don't have these yet.

backup and restore commands

A simple means to backup and restore an entire wordpress installation (files+configured db) would be very useful.

Use case:

backup
install plugin
...doh! my site is broken!
restore

Unexpected character in input: in wp-cli.php

First of all, the idea is great, it is a needed tool, like Drupal has its drush (drupal shell), so WP need cli to.
I installed it via git, and when I try to run wp commands (even wp help) I get the following error:

PHP Warning: Unexpected character in input: '' (ASCII=92) state=1 in /root/git/wp-cli/src/php/wp-cli/wp-cli.php on line 23
PHP Parse error: syntax error, unexpected T_STRING in /root/git/wp-cli/src/php/wp-cli/wp-cli.php on line 23

Create wp-config.php automatically?

Now that wp core download is part of source, there is a gap between that command and wp core install which I'd be interested in - automatically creating a wp-config.php file given the database details via arguments.

Perhaps something like this:
wp core config --database_name=db --user=db_user --user_pass=db_user_pass

And these parameters in combination with sed could parse wp-config-sample.php and create a wp-config.php.

Other parameters could be included... perhaps for setting up a multisite install, etc.

Just putting this out to start a discussion, anybody like?

Add global --blog parameter

When the --blog parameter is passed, it would trigger a call to switch_to_blog() (if multisite is enabled).

The command that would benefit from this most is theme activate, since setting up a theme for a particular blog using the normal MultiSite admin is very long-winded.

Example usage:

wp theme activate a-new-theme --blog=newblog

Ideally, you could pass the blog slug and not the blog id.

Introduce a global `wp` command

If you have multiple WP instances running, it would be great if you could install wp-cli in one place and then cd to a wp root directory and just run wp.

When you run a git command, it checks for a .git directory in the current path.

The wp command could check for the wp-admin directory instead.

Rename 'sql' command to 'db'

All the operations supported by 'wp sql' are actually referring to the WordPress database, not to the SQL language. So, I think 'db' would be a more appropriate name:

wp db connect
wp db dump
wp db cli
wp db query

I only noticed this after reading this comment: https://github.com/andreascreten/wp-cli/issues/44#issuecomment-3330593

`wp theme delete` command

Should be easy to add.

Problems with wp option when the option value has a `%`

I followed scribu's tutorial in wptuts and I wanted to use wp option get permalink_structure but I got the following error.

PHP Warning:  sprintf(): Too few arguments in /Users/iskay/git/wp-cli/src/php/php-cli-tools/lib/cli/cli.php on line 55

Warning: sprintf(): Too few arguments in /Users/iskay/git/wp-cli/src/php/php-cli-tools/lib/cli/cli.php on line 55

The option value is

wp eval "echo get_option('permalink_structure');"

/%year%/%monthnum%/%day%/%postname%/

If I change the value with something that doesn't contains % the command works.

<?php
// File: ~/git/wp-cli/src/php/php-cli-tools/lib/cli/cli.php

return call_user_func_array('sprintf', $args); 

There should be a way to escape % in a sprintf function.

wp eval

I find myself wanting to get the value of a constant or call some function. Instead of writing dedicated subcommands, why not just pass PHP directly?

Examples:

wp eval 'echo WP_CONTENT_DIR;'

wp eval 'require "some-file.php";'

Drush has php-eval and php-script.

wp plugin uninstall

It's sometimes useful to run the uninstall procedure of a plugin, but without deleting it afterwards.

This is currently not possible in either GUI or CLI.

Remove @author doc lines

Having @author Andreas Creten on each class method is rather excessive and doesn't encourage collaboration.

Contributors should only be mentioned in the README. Let git blame do the rest.

xcache_set(): xcache.var_size is either 0 or too small to enable var data caching

Getting the following on every command run:

Warning: xcache_set(): xcache.var_size is either 0 or too small to enable var data caching in /wp-content/plugins/w3-total-cache/lib/W3/Cache/Xcache.php on line 41

Fatal error in older wp version.

Hello,

I've been facing various memory exhausted errors in older version of wp while using wp-cli.

It occurs just by using wp help command.

So far I've had the bug with a 2.9 and a 3.2.1 release.

Here are the stack traces:

2.9:
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 311296 bytes) in /home/xxxx/xxxxx/wp-cli/src/php/wp-cli/commands/internals/export.php on line 454
PHP Stack trace:
PHP 1. {main}() /home/xxxx/xxxxxx/wp-cli/src/php/wp-cli/wp-cli.php:0

3.2.1:
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 39 bytes) in /home/xxxxx/www/xxxxxxx/wp-includes/pomo/mo.php on line 172
PHP Stack trace:
PHP 1. {main}() /home/xxxx/xxxxx/wp-cli/src/php/wp-cli/wp-cli.php:0
PHP 2. require_once() /home/xxxx/xxxxx/wp-cli/src/php/wp-cli/wp-cli.php:69
PHP 3. require_once() /home/xxxxx/www/xxxxxxx/wp-load.php:29
PHP 4. require_once() /home/xxxxx/www/xxxxxxx/wp-config.php:93
PHP 5. do_action() /home/xxxxx/www/xxxxxxx/wp-settings.php:302
PHP 6. call_user_func_array() /home/xxxxx/www/xxxxxxx/wp-includes/plugin.php:405
PHP 7. RGForms::init() /home/xxxxx/www/xxxxxxx/wp-includes/plugin.php:405
PHP 8. load_plugin_textdomain() /home/xxxxx/www/xxxxxxx/wp-content/plugins/gravityforms/gravityforms.php:85
PHP 9. load_textdomain() /home/xxxxx/www/xxxxxxx/wp-includes/l10n.php:416
PHP 10. MO->import_from_file() /home/xxxxx/www/xxxxxxx/wp-includes/l10n.php:337
PHP 11. MO->import_from_reader() /home/xxxxx/www/xxxxxxx/wp-includes/pomo/mo.php:27
PHP 12. unpack() /home/xxxxx/www/xxxxxxx/wp-includes/pomo/mo.php:172

I'm runing ubuntu with latest deb packages of php5.

Let me know if you need any more details.

`wp help subcommand` instead of `wp subcommand help`

That's how both svn and git do it.

Writing wp generate help just looks silly.

Will commit a fix shortly.

Plugin installation failure due to insufficient rights does not report this

When installing a plugin as a user without file-writing rights on the WordPress directory you are not being notified of this. See the below example, where the plugin is not being installed:

$ wp plugin install wp-super-cache
Installing WP Super Cache (1.0)
$ 

Here, a sudo is of course what should be preceding the command above, but an output would be nice.

`wp mu-plugin`

I think we should separate mu-plugin handling from the plugin command.

Most subcommands simply don't make sense for them: status, activate, deactivate, toggle, install, update.

The only subcommands that would work would be list, path and delete.

pear doesn't install bash completion file or man pages

To fix this, a custom role would have to be created:

http://pear.php.net/manual/en/guide.migrating.customroles.defining.php

http://pear.php.net/manual/en/guide.developers.package2.usesrole.php

fail in search for php exe on debian

I had a small issue with the test for the php exe..
In my Debian box the php5 exe is php5-cgi, and it seems the script is unable to find it..
I see I could set $WP_CLI_PHP and go with it, but that's not really immediate, so maybe it would be best to include a few more test for the php exe in the main script..

Memory limit problem

I'd really like to use wp-cli, but I'm running into a problem with a hard memory limit on an Ubuntu box.

On running wp I get error:
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 30720 bytes) in /path/to/wordpress/wp-admin/ includes/post.php on line 635 PHP Stack trace: PHP 1. {main}() /path/to/git/wp-cli/src/php/wp-cli/wp-cli.php:0 PHP 2. require_once() /path/to/git/wp-cli/src/php/wp-cli/wp-cli.php:91

The problem is not resolved by editing php.ini and increasing the memory limit, because of an issue described here:
http://stackoverflow.com/questions/3318636/how-else-might-a-php-cli-script-determine-its-memory-limit

In summary, Linux on 32bit and 64bit (I have 64 bit) machines seems to have a heap limit, which makes the max memory allocation for PHP CLI 4MB/8MB, regardless of what you set in php.ini. (The 'unlimited' option is actually 4MB, and if you set it to 5MB in php.ini it actually goes down in reality to 1MB!)

This kind of memory stuff is way outside my comfort zone - but I wonder if there's a way to do something in the code to free up some memory?

Install development version of plugins

It should be pretty easy to add a --dev flag to wp plugin install that would cause the installer to download the development version, instead of the stable version.

Some inspiration: http://developersmind.com/wordpress-plugins/wp-plugin-installer/

`wp test` Unit tests via WP Unit

I have created a new command for WP Unit tests (base plugin is here: http://wordpress.org/extend/plugins/wp-unit/ ).

I have gist'ed the command here: https://gist.github.com/1279697 for any feedback / any wants to give it a go.

wp test show will display all available test cases

wp test run MyTestCase will run the specified test case.

wp test run Will run all available tests.

I also have some modifications for WP Unit if anyone is interested (automatic tests inclusions etc)

Use Console_Getopt class?

There's a pear package for parsing cli options: http://pear.php.net/package/Console_Getopt

Documentation: http://pear.php.net/manual/en/package.console.console-getopt.intro-options.php

It's the most recently updated of the bunch, currently:

http://pear.php.net/packages.php?catpid=5&catname=Console