---

This section details on the original issue you should resolve

<issue_title>Helper function Utils\has_stdin() misfires depending on shell environment</issue_title>
<issue_description>Given a command like:

wp option patch update gglcptch_options login_form 0

run on a non interactive shell (like through atd/crod/puppet exec) we receive an Error:

Error: No data exists for key "0"

if we run the same program through the command line everything works fine.

Taking a look at the code here

https://github.com/wp-cli/entity-command/blob/v1.2.0/src/Option_Command.php#L525

and trying the command:

echo 1 | wp option patch update gglcptch_options login_form

gave us the expected results even in atd/crod/puppet exec shells.
</issue_description>

Comments on the Issue (you are @copilot in this section)

@schlessera At first glance, this looks like a bug in the argument parsing code.

I could reproduce it by adding < /dev/null to it:

$ wp option patch update wp_user_roles administrator capabilities unfiltered_html false
Success: Updated 'wp_user_roles' option.

$ wp option patch update wp_user_roles administrator capabilities unfiltered_html false < /dev/null
Error: No data exists for key "false"

I suppose it detects the < /dev/null as a valid STDIN input. This makes it pick STDIN as value, so the actual value we had provided gets interpreted as a key as well.</comment_new>
<comment_new>@schlessera
Some more details on this bug after trying to resolve it without success yesterday...

The root cause lies in WP_CLI\Entity\Utils::has_stdin(). Under some circumstances (due to the way the surrounding shell has called the process), the stream on STDIN is present, but returns an empty value.

This in turn will cause the above logic to miscount the arguments.

I fixed the symptom in the above code in the following way:

$stdin_value = WP_CLI\Entity\Utils::has_stdin()
	? trim( WP_CLI::get_value_from_arg_or_stdin( $args, -1 ) )
	: null;
$patch_value = ! empty( $stdin_value )
	? WP_CLI::read_value( $stdin_value, $assoc_args )
	: WP_CLI::read_value( array_pop( $key_path ), $assoc_args );

So, for the option patch call, the problem is fixed with v2. However, I didn't yet solve the root cause in WP_CLI\Entity\Utils::has_stdin(), so places where we cannot just trick with the values are not yet fixed.

The one case I know of so far is wp user import-csv -.</comment_new>
<comment_new>@schlessera
Related wp-cli/entity-command#194 </comment_new>
<comment_new>@schlessera
@soderlind I already experimented with a similar approach, reading the mode directly, but the main issue is not detecting what type of pipe we have, but rather, whether the pipe has content or not. Did you find a way to do that through the above (mode-based) method, or did you only test for the type of pipe?</comment_new>
<comment_new>@schlessera
@soderlind The above code for reading from STDIN would be a blocking request, though. That works fine if you can rely on STDIN content being available. But if the content is not available, WP-CLI will just hang, without the user knowing what is going on...

I'll experiment some more with this, maybe it is just about finding the right combination of checking mode and reading/skipping.</comment_new>