Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add support for common Windows commands #569

Conversation

xtrasimplicity
Copy link
Member

@xtrasimplicity xtrasimplicity commented May 26, 2018

Summary

On Windows, as on Linux, Aruba knows how to handle running applications that are in the user's PATH environment variable. Unlike on Linux, however, some windows commands (such as echo) are built-in to the command prompt and are not standalone executables.

Currently, running echo from Aruba on a Windows computer will fail the scenario with Command "echo" not found in PATH-variable errors. This PR aims to resolve this.

Details

I've added the ability to define commands that should always be prefixed with cmd.exe /c, in internal_shell_commands under each platform's class.

I then check whether the command that couldn't be found in PATH is an internal shell command, and if so, bypass the call to fail. Aruba.platform.command_string then kicks in and prepends cmd.exe /c as usual.

Motivation and Context

The AppVeyor CI builds are failing on Windows as many of the scenarios are incompatible due to their use of echo and other commands. Rather than tag the failing scenarios with @not-supported-on-platform-windows, which will reduce the test coverage for Windows, I figured we should look at fixing the issue and only use that tag when we really need to.

Please see #568 for further information.

How Has This Been Tested?

No additional tests have been added. Instead, these changes fix some of the previously failing tests (e.g. features/02_configure_aruba/working_directory.feature)

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactoring (cleanup of codebase without changing any existing functionality)
  • Update documentation

Checklist:

  • I've added tests for my code
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

@xtrasimplicity
Copy link
Member Author

Closing as I've cherry-picked these changes into #505.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant