Steps to reproduce:
1. Open SampleScene in the attached "Unity hub v3 PATH problem.zip" project
2. Enter Play Mode
3. Observe log message in the Console window and then close the project
4. Launch the user attached project from the macOS Terminal using the command line arguments following this structure: <unity_instalaltion_path> -projectPath <project_path>
5. Open SampleScene and Enter Play Mode
6. Observe log message in the Console window

Expected result: output of the PATH variable in the Editor's Console window is the same when the project is launched via the Hub and via the Terminal
Actual result: output of the PATH variable in the Editor's Console window is different when the project is launched via the Hub from when the project is launched via the Terminal

Reproducible with: 3.0.1, 3.1.0-beta.2

Notes:
- This issue is not reproducible on Windows and Linux
- The issue can also be observed when typing "echo $PATH" without the quotation marks in macOS Terminal
- In the repro project, the environment variable is gotten using "Environment.GetEnvironmentVariable("PATH")" method
- Project's Console window output when launching it via the Hub: "/usr/bin:/bin:/usr/sbin:/sbin"
- Project's Console window output when launching it via the Terminal: "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands"

*Additional notes from discussion between [~lara.rode] and myself ([~paul.jarrow]):*

In some cases, the PATH that the Hub is collecting includes junk from stdout that shouldn't be there. This muddies the PATH variable and creates a lot of undefined behaviour. This was effecting some Mac users of the Hub, preventing them from installing the Unity Editor with the error: ENAMETOOLONG. A small fix has been created for this problem, but there appears to be a larger issue that should be addressed here.

The fix for the above ENAMETOOLONG error was to provide the option *shell: true* to the spawn function in the Hub.