Conversation
|
Hello! 👋 Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this 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. Here are some useful Composer commands to get you started:
To run a single Behat test, you can use the following command: # Run all tests in a single file
composer behat features/some-feature.feature
# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123You can find a list of all available Behat steps in our handbook. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates Behat feature files to improve cross-platform compatibility by replacing /dev/null with a temporary file and switching from single to double quotes in shell commands. However, the use of double quotes for the password argument in features/config-create.feature introduces a regression on POSIX-compliant systems because the shell will interpret the backslash escape sequences differently than on Windows.
| And WP files | ||
|
|
||
| When I run `wp config create --skip-check --dbname=somedb --dbuser=someuser --dbpass='my\\password'` | ||
| When I run `wp config create --skip-check --dbname=somedb --dbuser=someuser --dbpass="my\\password"` |
There was a problem hiding this comment.
This change to use double-quotes, while beneficial for Windows compatibility elsewhere, introduces a regression for this specific test case on POSIX-compliant systems like Linux and macOS.
- On Windows
cmd.exe,"my\\password"is passed to the program as the stringmy\\password. - On POSIX shells (e.g., bash),
"my\\password"is interpreted asmy\passwordbecause the shell processes the\\escape sequence.
This difference in shell behavior will cause this test to fail in non-Windows environments, as the test expects the password argument to be my\\password.
Please find a cross-platform compatible way to quote this argument. This can be tricky due to shell differences. An alternative could be to adjust the test itself to use a password that doesn't have this ambiguity.
1 participant
No description provided.