Bug Report

• [x] Yes, I reviewed the contribution guidelines.
• [x] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

When doing any command in wp shell when SSH'd into a remote server, I get a path to the WP-CLI REPL file returned to me before the correct output.

Describe how other contributors can replicate this bug

wp> wp_revisions_to_keep( get_post( 3451690 ) );
=> phar:///root/roles/docker-container-web/usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php:52:
int(50)

Describe what you would expect as the correct outcome

That this path should not appear when using the simplistic REPL.

wp> wp_revisions_to_keep( get_post( 3451690 ) );
int(50)

Let us know what environment you are running this on

OS:	Linux 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64
Shell:	/bin/bash
PHP binary:	/root/roles/nginx-php/usr/local/php7.3/bin.stretch/php
PHP version:	7.3.16
php.ini used:	/usr/local/php7.3/conf/php.ini
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:	/home/vipdev
WP-CLI packages dir:	/home/{redacted}/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.4.0

Provide a possible solution

Maybe remove or fix this var_dump()?

Basically I have a shared hosting site, that has well,

[vhost68584ssh@procyon ~]$ which bash
/usr/local/bin/bash
[vhost68584ssh@procyon ~]$ /bin/bash
-bash: /bin/bash: No such file or directory

which means no shell-cookie-sugar-coated-sweetness for me :(

But as I am not actually a PHP person, I need some tips and pointers on how to get started with this functional testing point "3. Please make sure to include functional tests for your changes." Examples maybe :)

Related: /wp-cli/issues/4302

Improve wp shell command description in: https://github.com/wp-cli/shell-command/blob/master/src/Shell_Command.php https://github.com/wp-cli/shell-command/blob/master/README.md

Current description: Interactive PHP console.

New description: Opens an interactive PHP console for running and testing PHP code.

wp> namespace dustinpaluch { }
PHP Parse error:  syntax error, unexpected 'dustinpaluch' (T_STRING), expecting \\ (T_NS_SEPARATOR) in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/REPL.php(37) : eval()'d code on line 1

I'm trying to reproduce a bug involving namespaces, wp actions, and anonymous functions, and was hoping I'd be able to use the wp shell to make a minimal test case.

In the documentation on WordPress.org, the flag --basic is described as follows:

[--basic] Start in fail-safe mode, even if Boris is available.

What is Boris?

Steps to reproduce:

1. Execute these commands:

wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "100"
wp> update_post_meta( 139, '_price', 200 )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
bool(true)
wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "200"

2. Leave the wp shell running in background, and in a different session run this DB query:

mysql> update wp_postmeta set meta_value = '123' where post_id = 139 and meta_key = '_price';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

3. Go back to the wp shell, and run this:

wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "200"
wp> 

If you close and open wp shell again, it will return the correct value:

boro@bor0:~/dev/www/wordpress$ wp shell
wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "123"
wp> 

Right now, using PsySH as the alternative shell implementation requires a rather technical change to the internals of WP-CLI:

• Either completely install WP-CLI through Composer, instead of using the Phar
• Or directly edit the ~/.wp-cli/packages/composer.json file

I'd like to create a new package wp-cli/shell-psysh that you can just install through the WP-CLI package manager to replace the default shell instead (naming of the package up for discussion of course).

Bumps andstor/file-existence-action from 1 to 2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on wp-cli/wp-cli-tests to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello! Thanks for this amazing project!

I found a small bug while trying to integrate with PsySH, seems like an incorrect command is used to initialize PsySH:

This happens because Psy\Shell::debug() is used to introduce breakpoints.

Note that Psy\Shell->run() is also used by all other integrations: https://github.com/bobthecow/psysh/wiki/Integrations

Originally reported by @hiobama in #34:

If exit wp-shell by ctrl + c, some processes will always running there, never give up, slow down your computer.

Feature Request

• [x] Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Making typos/etc often results in a fatal error, and the session crashes and has to be restarted. After restarting, I have to recreate any variables, includes, etc from scratch, without making any fatal errors. That often makes it just too frustrating to use.

> wp shell
wp> require 'foo.txt';
Warning: require(foo.txt): Failed to open stream: No such file or directory in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code on line 1
Fatal error: Uncaught Error: Failed opening required 'foo.txt' (include_path='.:/usr/local/Cellar/php/8.0.0_1/share/php/pear') in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code:1
Stack trace:
#0 phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32): eval()
#1 phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/Shell_Command.php(51): WP_CLI\Shell\REPL->start()
#2 [internal function]: Shell_Command->__invoke(Array, Array)
#3 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(98): call_user_func(Array, Array, Array)
#4 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(451): call_user_func(Object(Closure), Array, Array)
#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(371): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#7 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(394): WP_CLI\Runner->run_command(Array, Array)
#8 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1160): WP_CLI\Runner->run_command_and_exit()
#9 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#10 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(74): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#11 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(27): WP_CLI\bootstrap()
#12 phar:///usr/local/bin/wp/php/boot-phar.php(11): include('phar:///usr/loc...')
#13 /usr/local/bin/wp(4): include('phar:///usr/loc...')
#14 {main}
  thrown in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code on line 1
Error: There has been a critical error on this website.Learn more about debugging in WordPress. There has been a critical error on this website.

Describe the solution you'd like

PHP's REPL is able to catch fatals and continue running:

php > $foo = 'stuff';
php > echo $foo;
stuff
php > require 'foo.txt';

Warning: require(foo.txt): Failed to open stream: No such file or directory in php shell code on line 1

Warning: Uncaught Error: Failed opening required 'foo.txt' (include_path='.:/usr/local/Cellar/php/8.0.0_1/share/php/pear') in php shell code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1
php > echo $foo;
stuff

Is that possible for wp shell ?

Feature Request

Add support for default shell on OpenBSD (ksh).

Describe your use case and the problem you are facing

Trying to use wp shell cmd under OpenBSD results in errors and exits prematurely.

$ wp shell
/bin/ksh: fc: history functions not available
/bin/ksh: read: -e: unknown option
$ echo $?
0

$ wp cli info
OS:     OpenBSD 6.6 GENERIC.MP#584 amd64
Shell:  /bin/ksh
PHP binary:     /usr/local/bin/php-7.3
PHP version:    7.3.13
php.ini used:   /etc/php-7.3.ini
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:       /var/www/htdocs
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.4.0
$ env | grep WP_CLI_CUSTOM_SHELL
WP_CLI_CUSTOM_SHELL=/bin/ksh

Describe the solution you'd like

Quick win:

Add some more detection at shell instantiation to detect shell and platform to enable running in ksh on OpenBSD.

Nice to have:

Test in a few different shell/OS environments and modify to run across more - else, fail gracefully when unsupported.

Happy to work on this

I haven't had the chance to dig into this further, but just wanted to log this somewhere to prevent forgetting about it.

Assigning a value to $line in wp shell gives very unexpected results, causing some pretty confusing behavior and bugs.

Behavior:

wp shell

wp> $line = 'this wont work';
=> string(14) 'this wont work'
wp> $line;
=> string(13) "return $line;"

wp> $linetest = 'this will';
=> string(9) "this will"
wp> $linetest;
=> string(9) "this will"