Issue overview
--------------
I am opening this issue primarily for @jmarrec a…fter [asking an initial question on another issue](https://github.com/NREL/OpenStudio/issues/5069#issuecomment-1986642054). The issue is that, whenever OpenStudio is installed in a file path with a space (for example, the `C:\Program Files` directory that IT departments make us use), we get the following message when running an OSW with a reporting measure using OpenStudio CLI:
```
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.
RunEnergyPlus: Completed Successfully with 0 Fatal Errors, 0 Severe Errors, 34 Warnings.
```
## Current Behavior
The message does not indicate a complete OpenStudio CLI failure since the OSW run still completes successfully, including a successful run of EnergyPlus and the creation of reports from reporting measures specified in the OSW. However, it seems that whatever part of the OpenStudio 3.7 code that is producing this exception prevents us from seeing the progress of the reporting measure, whether it's the log of steps running in the measure or any adapters specified in the OSW, like those that allow us to see the progress of the EnergyPlus simulation as the OSW is being run.
## Expected Behavior
In OpenStudio 3.6.1, we did not get this message about "'C:/Program' is not recognized as an internal or external command," and we would instead see the logs of the reporting measure being run as well as the adapter we use giving us a full report of the EnergyPlus simulation as it was run. For example, at a minimum, we would see the following:
```
ExpandObjects Started.
No expanded file generated.
ExpandObjects Finished with Error(s). Time: 0.016
RunEnergyPlus: Completed Successfully with 0 Fatal Errors, 0 Severe Errors, 34 Warnings.
```
... and, if we had an adapter specified in the OSW, we would see the full EnergyPlus progress.
## Steps to Reproduce
I know that @jmarrec is not a Windows user so I think he may be able to create the issue on his end just by installing OpenStudio in a path with a space in it and trying to run the [OpenStudio Results measure](https://github.com/NREL/openstudio-common-measures-gem/tree/develop/lib/measures/openstudio_results) on any model (using the `/path with spaces/openstudio/bin/openstudio` to call the OpenStudio CLI executable). With this, I think he should be able to see the exception message and at least figure out where it is coming from with the OpenStudio code without the need to do a whole Windows setup. Also, he should not need to set up an adapter in the OSW or do anything fancy just to see this initial problem. The issue appears to be more deeply related to the ability to log the progress of reporting measures and not specific to the adapter as I originally thought.
If anyone else wants to recreate the issue or if my suggestion above does not work, I have a minimal OSW file that will work on Windows as long as the OpenStudio executable is installed in `C:\Program Files\openstudio\bin\openstudio.exe` (or another path with a space in it). Here is the zip file of the sample:
https://drive.google.com/file/d/16Rb6gnid0JOxPlcLd78du7F0A5R96x3J/view?usp=sharing
And, if you extract it, this is what you should see:
You have a small shoe box OSM, a Boston EPW and a workflow.osw that is meant to run only the OpenStudio Results measure, all out of a C:\test_osm` directory. Here are the contents of that simple OSW JSON:
```
{
"seed_file": "C:\\test_os\\in.osm",
"weather_file": "C:\\test_os\\USA_MA_Boston-Logan.Intl.AP.725090_TMY3.epw",
"steps": [
{
"arguments": {
"schedules_overview_section": true,
"space_type_breakdown_section": true,
"plant_loops_detail_section": true,
"measure_warning_section": true,
"plug_loads_section": true,
"zone_equipment_detail_section": true,
"outdoor_air_section": true,
"air_loops_detail_section": true,
"envelope_section_section": true,
"space_type_details_section": true,
"source_energy_section": true,
"monthly_overview_section": true,
"water_use_section": true,
"interior_lighting_section": true,
"hvac_load_profile": true,
"building_summary_section": true,
"annual_overview_section": true,
"utility_bills_rates_section": true,
"units": "IP",
"reg_monthly_details": false,
"exterior_light_section": true,
"cost_summary_section": true,
"zone_summary_section": true,
"zone_condition_section": true
},
"measure_dir_name": "openstudio_results"
}
]
}
```
Just run the OSW using:
```
cd C:\test_os
"C:\Program Files\openstudio\bin\openstudio.exe" run -w workflow.osw
```
... and you should see the issue.
## Possible Solution
I have a feeling that all that is needed to fix this issue is that the path to a file or folder needs to be put in "double quotes" somewhere in the OpenStudio code. This way, the full path will be interpreted by the command line and it won't try to interpret 'C:/Program' as a command.
### Environment
I'm running on Windows 10 but, as I said, I think any OpenStudio installation with a space in the path should illustrate the issue.
### Context
This is not a deal breaker for us upgrading to OpenStudio 3.7 since, as I said, the OSW files are still running and producing the correct outputs. However, several of our users are starting to complain that "OpenStudio is frozen" since they can't see any logging or progress of the reporting measure. [Here is an example](https://discourse.pollination.cloud/t/energy-simulation-issue-with-ver-po-v1-43-8-0/3699).
Thanks, as always.
