[Windows] Aruba doesn't know how to run "built-in" DOS commands

[xtrasimplicity]

Summary

On Windows, as on Linux, Aruba knows how to handle running applications that are in the user's PATH environment variable, however unlike on Linux it doesn't know how to run commands built-in to the command prompt, such as cd and echo. This most likely works on Unix due to cd and echo being executables in their own right.

Expected Behavior

Feature: Running "built-in" DOS commands on Windows
  Scenario: Running 'echo' from within Aruba
    Given a directory named "test_directory"
    When I run `cd test_directory`
    And I run `echo %cd%`
    Then the output should match %r<\tmp\aruba\test_directory$>

should echo \tmp\aruba\test_directory to the console.

Current Behavior

Currently, when you run cd or echo from Aruba on Windows, it fails with the stacktrace below.

Feature: Running "built-in" DOS commands on Windows
  Scenario: Running 'echo' from within Aruba
    Given a directory named "test_directory"
    When I run `cd test_directory`
    And I run `echo %cd%`
    Then the output should match %r<\tmp\aruba\test_directory$>

Command "echo" not found in PATH-variable "C:/Users/Andrew-W7Mgmt/Documents/Development/aruba/bin;C:/Users/Andrew-W7Mgmt/Documents/Development/aruba/exe;C:/Ruby25-x64/lib/ruby/gems/2.5.0/bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Ruby25-x64\bin;C:\Program Files (x86)\Spiceworks\Nmap;C:\Program Files (x86)\Microsoft VS Code\bin;%DASHLANE_DLL_DIR%". (Aruba::LaunchError)
./lib/aruba/processes/spawn_process.rb:281:in `command_string'
./lib/aruba/processes/spawn_process.rb:74:in `start'
./lib/aruba/command.rb:71:in `start'

Possible Solution

I was thinking of updating lib/aruba/processes/windows_which.rb to "map" built-in DOS commands such as echo and cd (without arguments) such that it returns the command prefixed with the path to cmd.exe and the /c argument. e.g. `C:\windows\system32\cmd.exe /c "echo {additional_args}".

I suspect this may become very messy, however, especially when the user wants to pass multiple arguments.

Steps to Reproduce (for bugs)

1. Create a new Application with Cucumber and Aruba installed.
2. Copy the feature definition above to a file and run it via cucumber /path/to/feature on a Windows machine.

Context & Motivation

I was trying to fix up the AppVeyor build without negatively impacting our Windows-based test coverage and ran into this when creating alternative, Windows-specific scenarios using cd or echo %cd%.

Your Environment

• Version used: Branch-specific ([WIP] [Rebased] Improve AppVeyor build #567). I'll test this out on master soon.
• Operating System and version: Windows 7 Pro
• Link to your project: [WIP] [Rebased] Improve AppVeyor build #567

[xtrasimplicity]

#521 seems to be related.

[xtrasimplicity]

I've been able to put together a fix to get echo to work, but cd won't really work if prefixed with cmd /c due to the way the process is spawned. i.e.

Scenario: Changing to a directory on Windows
  Given a directory named "test.d"
  When I run `cd test.d`                <--- this will spawn a new `cmd.exe` process with the `/c` flag and terminate on completion.
  And I run `cd`                             <--- this will show the directory where the user was _before_ changing to `test.d`
  ....

I don't think we'll be able to use cmd with the /k flag, as it would effectively become 'interactive' and wait for further input (and an explicit exit signal).
Any ideas?

Combining both the cd and echo calls in the same step definition works as expected (i.e. cd test.d && echo %cd% or cd test.d && cd) - maybe there isn't really anything we can do?

[xtrasimplicity]

I was just thinking about this again.. Perhaps if we somehow changed Aruba's "context" such that, on Windows, it runs within a single command prompt instance which aborts on scenario completion? Or at some other trigger, so that we're not tightly coupling things?

To be clear, if we were to do this, processes executed by Aruba would be executed from within the "master" command prompt process. I.e.

Aruba --> instance of "cmd /k" (A) --> command executed from step. (B)
Then on completion, process B would terminate but process A would remain until (a) the scenario finishes, or (b) some other (to be determined) event occurs. Subsequent commands executed within the scenario, by Aruba, would be executed from process A.

The other option I've thought of is mapping commands directly to their ruby alternative (FileUtils.chdir for cd, not sure how we'd handle echo - maybe puts?), prefixing the directory with Aruba's /tmp/aruba/, but I'm not sure if this would mess up the shell session that triggered cucumber to begin with? My first thought would be that it wouldn't, but I'll have to check. This would ultimately mean we would have to map each command manually, though.

Do you guys have any thoughts? @olleolleolle, @mvz, @aslakhellesoy

[xtrasimplicity]

It looks like this is a limitation of ChildProcess: https://github.com/enkessler/childprocess/blob/master/README.md#invoking-a-shell

I'll have a play around to see if I can work around this. If not, I may have to look upstream. :)

[mvz]

What happens if you run the scenario with cd test.d on Unix? I'm guessing it won't "work" there either, because Aruba will set the working directory for each command spawning. If that is the case, I don't think there's a need to make it work on Windows.

[mvz]

Another thing that I'm wondering about is: How do people developing a gem with an executable on Windows invoke said executable while developing? Knowing this may help in coming up with a reasonable scenario.

[xtrasimplicity]

What happens if you run the scenario with cd test.d on Unix? I'm guessing it won't "work" there either, because Aruba will set the working directory for each command spawning. If that is the case, I don't think there's a need to make it work on Windows.

Excellent catch there, @mvz! I've just double checked this and can confirm that you're correct. When transposing an existing feature to be Windows-compatible, it seems I misread When I cd to "dir.d" as When I run cd "dir.d".

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

[xtrasimplicity]

I'm going to close this off, as it has been included as part of #505

[mvz]

Re-opening since #505 hasn't been fully merged yet.