@porg The latest stable seems to work fine for me...

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6831k  100 6831k    0     0  34.6M      0 --:--:-- --:--:-- --:--:-- 34.7M
$ php wp-cli.phar theme status "twentytwentythree"
Theme twentytwentythree details:
    Name: Twenty Twenty-Three
    Status: Active
    Version: 1.0 (Update available)
    Author: the WordPress team

Can you share wp --info? Maybe you have some odd PHP configuration?

This is what I get on my shared webhosting service:

$ wp --info
OS:	Linux 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php8.0
PHP version:	8.0.28
php.ini used:	/etc/php/8.0/cli/php.ini
MySQL binary:	/usr/bin/mysql
MySQL version:	mysql  Ver 14.14 Distrib 5.7.40-43, for debian-linux-gnu (x86_64) using  7.0
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/data/web/customer-id
WP-CLI packages dir:	/data/web/customer-id/.wp-cli/packages/
WP-CLI cache dir:	/data/web/customer-id/.wp-cli/cache
WP-CLI global config:	/data/web/customer-id/.wp-cli/config.yml
WP-CLI project config:	
WP-CLI version:	2.10.0

My guess is that phar_safe_path() is failing:

https://github.com/wp-cli/extension-command/blob/80713703e090fbc74926af6f75bf963619f76fdb/src/Theme_Command.php#L886-L898

Can you launch wp shell and share the return value of WP_CLI\Utils\inside_phar()?

Huh!

Can you try re-downloading WP-CLI? What does md5 <wp-cli-path> give you?

md5 not available in the shell of the webhost.

In the European evening I will download the binary via SFTP and then md5 on my computer.

FYI: The current wp-cli binary has been installed via its own update mechanism wp cli update .

$ wp cli update
Success: WP-CLI is at the latest version.

• There is no possibility to run wp cli update with a --force flag to re-download and re-install.
• I could run the curl oneliner to re-install. Shall I?
• Or shall I try the nightly?
• Could I downgrade again later?
  • Is wp-cli shipped "all in one file"? (Seems so at first glance at the curl oneliner)
  • So install is effectively only the download of a single file .phar file and making it executable (via shebang) or else run invoke it with php before it. But when running the first time, is it installing libraries or config files elsewhere?
  • If not, then I assume downgrading to the stable should be possible.

Is wp-cli shipped "all in one file"? (Seems so at first glance at the curl oneliner)

Yes, as a Phar file ("PHP Archive").

I could run the curl oneliner to re-install. Shall I?
Or shall I try the nightly?

Based on your md5 results, it seems you have the correct file for WP-CLI v2.10.0.

But, wp-cli/core-command#160 looks like a similar report where the user saw different results based on which URL they downloaded the Phar from.

Can you try downloading a new copy of WP-CLI using curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar and seeing if the problem reproduces with the new copy?

Generally I believe in computing to be a deterministic discipline

• … though in over 3 decades of experience I had some occasions where after all debugging was exhausted it may shortly felt as if voodoo was involved 😂.
• Your forementioned issue where a file with the same MD5 checksum produces a different outcome depending from where it was downloaded, again seems too much voodoo to me! I don't believe this to be the true cause.
• Eventually in a deterministic machine, there is always some kind of real difference, which makes the difference, which we oversee. Be it a filesystem timestamp (which strangely is involved in whatever logic), or faulty permissions which the re-download somehow corrects, or be it even an odd bug like an xattr, which kept the download URL, which as far etched as it may seem nevertheless makes a difference for some very very odd reason. Whatever insignificant bit of data or metadata it ever may be, I've experienced it all 😉

But in our case here, it is rather some PHP env/runtime difference (e.g. Object Cache which I have ON) or some faulty PHP files in WordPress Core (although I never touched them), with which wp-cli interfaces, I assume.

My conducted testing which lead to no difference yet

1. In my ~/bin I noticed file wp-completion.bash.

• Deleted it.
• Ran wp theme status "twentytwentythree" again.
• Same error as before.

2. Logged out and into my shell again, my bash complained about a missing wp-completion.bash which is sourced in ~/.bashrc.

• So in this state wp-completion.bash was definitely not in action.
• Ran wp theme status "twentytwentythree" again.
• Same error as before.

3. Downloaded via the curl-oneliner, removed the old phar file, renamed the downloaded to just wp.

• Ran wp theme status "twentytwentythree" again.
• Same error as before.

4. Due to having no possibility to run shebang executables in the SSH environment of my shared webhosting, in my .bashrc I have had alias wp="php ~/bin/wp" for a while now.

• Ran explicitly php ~/bin/wp theme status "twentytwentythree".
• Same error as before.

Any more ideas?

Please note: Personally I don't care for this bug.

• I just spotted it by coincidence in a use case which I may use only once every year or so.
• Instead of wp theme status <specificTheme> I can just run wp theme status get the whole report and then look at my <specificTheme> of interest.
• But some people who may rely on that function for automation, may get a problem with it.
• Hence I took it to heart to report and take part in debugging it. But from my side my curiosity in this is done, and from myself I would not further look into this, but just accept it as is.
• If you deem this as worthy to further investigate, please tell me what I should be looking for.

Oh, it's definitely a bug, I don't deny that. I don't have any ideas what it might be.

If I was able to reproduce the issue, I'd open the Phar file in vim and add some debugging checkpoints around the code in question.

@wp-cli/committers Any ideas what the issue might be?

I tried to reproduce this issue in my Mac and Windows setup but could not. I tried several combination like; WP CLI 2.10 and WP CLI latest and also WP 6.4 and WP 6.5

I'm running into this issue and it seems to me to have something to do with the name of the phar itself. I've reproduced this on Windows (Ubuntu WSL) and Debian bookworm. I've downloaded the latest phar directly from Github and tested this:

$ php wp-cli.phar plugin status akismet
Plugin akismet details:
    Name: Akismet Anti-spam: Spam Protection
    Status: Inactive
    Version: 5.3.3
    Author: Automattic - Anti-spam Team
    Description: Used by millions, Akismet is quite possibly the best way in the world to <strong>protect your blog from spam</strong>. Akismet Anti-spam keeps your site protected even while you sleep. To get started: activate the Akismet plugin and then go to your Akismet Settings page to set up your API key.
$ mv wp-cli.phar wp
$ php wp plugin status akismet
Error: Couldn't find plugin-status.mustache
$

This behavior presents itself whether running the phar explicitly from the php executable or when making it executable and executing it directly, either relatively or in the PATH.

In debugging, this comes down to a difference between getcwd() and __DIR__ (and __FILE__). The constant WP_CLI_PHAR_PATH, which is the basis of what phar_safe_path() strips out the absolute filesystem path from phar:// paths, is defined using getcwd(). Most uses of phar_safe_path() will pass in some value derived from __DIR__. When wp-cli.phar is compiled, its internal file dictionary is hard-coded to use wp-cli.phar, so changing the file's name doesn't affect its internal pointers. However, it does affect __DIR__, which will use the outer filesystem's name in the path.

I'm really not sure if there's an easy general solution, but this is what seems to be causing the problem.

After some more tinkering, I think I have a fairly efficient general solution. I'll be creating a pull request shortly.

I can confirm that in my environment I have had my wp-cli.phar renamed to wp.

Interestingly even --info seems to contain that hardcoded assumption of being named wp-cli.phar because in my wp --info output it said:

WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor

although in reality the file was just named wp.

Does your pull request also correct that "somehow untrue" --info output?

No, that was outside of the scope of the issue I was fixing. Once wp-cli/wp-cli-bundle#649 is merged, there's no reason that output couldn't be updated quite easily. Whether it would be accepted or not is another question I can't answer, though.

@johnpbloch ok thanks for the info. I filed #5964 if what I observed is indeed a misrepresentation.