Project path with spaces causes problems with packaging

UE 4.11.2, binary from Epic Launcher. Mac OS X 10.11

Attempting to “Zip Up Project” with target path containing spaces.
By mysterious reason the path is neither escaped nor quoted, here’s output log citation:

...
MainFrameActions: Zip Project Task (Mac): CommandUtils.Run: Run: zip -g -q /Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong_20160517-IZ.zip "Pong.uproject" ...
...

As a result, in this case ZIP archive is created with the name /Users/ingvarr/work/_tests/2016.05 which is frustrating.

Possibly related citation from “Packaging for Mac”:

...
MainFrameActions: Packaging (Mac): Start UAT: mono AutomationTool.exe -ScriptsForProject=/Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong/Pong.uproject BuildCookRun -nocompile -nocompileeditor -installed -nop4 -project=/Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong/Pong.uproject -cook -stage -archive -archivedirectory=/Users/ingvarr/work/_tests/201605TFG -package -clientconfig=Development -ue4exe=UE4Editor -prereqs -nodebuginfo -targetplatform=Mac -build -CrashReporter -utf8output
...
MainFrameActions: Packaging (Mac): Automation.ParseCommandLine: Parsing command line: -ScriptsForProject=/Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong/Pong.uproject BuildCookRun -nocompile -nocompileeditor -installed -nop4 -project=/Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong/Pong.uproject -cook -stage -archive -archivedirectory=/Users/ingvarr/work/_tests/201605TFG -package -clientconfig=Development -ue4exe=UE4Editor -prereqs -nodebuginfo -targetplatform=Mac -build -CrashReporter -utf8output
...

However, this does not cause wrong output locations.

Have you tried this without spaces in the target path?

Yes, and it certainly works.
In the first sample:
zip -g -q /Users/ingvarr/work/_tests/2016.05 - futuregroup/Pong_20160517-IZ.zip
the command is almost correct, only spaces break it. With spaceless path it finishes successfully.

What else confused me. In case spaces are present and output file is located at the wrong path, there are no notifications of error. Seems that UE4E does not check the output file, which is not good.

With the second example it is unclear to me how “-ScriptsForProject” option works. I have not investigated that deeply.

Sorry. Placed originally in the wrong space.

Just to clarify, are these the two issues you are having?

  1. Space in the directory path name is causing packaging to fail but is not flagged as an error in the packaging log.
  2. “-ScriptsForProject” is causing ZIP archive to be created with the wrong name.

If these are not correct descriptions of the problems, please describe as clearly as possible.

Also, what is the correct/expected name you are getting with no spaces (“spaceless”) path?

  1. Packaging succeeds. But the file has different name — the first part of the path before space. In other words, it works, but incorrectly.
  2. I’ve noticed suspicious “-ScriptsForProject” in another action (“Packaging for Mac”). The reason I’ve mentioned it is that I supposed it is a related problem: insufficient string escaping in Mac version.

Can you please clarify your last question?.. In case target path contains space (AAA/BBB/C CC/Q.ZIP) I get ZIP archive named by the first part of the string (AAA/BBB/C). In case of spaceless path (AAA/BBB/CCC/Q.ZIP) I get it where expected.

Hi darthpoo,

Thanks for responding with the requested clarifications. Answering your last question first, your example answered my question.

After more research I discovered that having spaces in the path name has caused more than one issue and has been reported as a bug. For now, I suggest simply not including spaces in path names (or any names) and instead use an underscore, if an intentional space is desired.

As for the “-ScripstForProject,” one of our developer’s explained: “By default, the Unreal Automation Tool will find and compile all .Automation.csproj files in your current branch. If you have multiple projects in the same branch this parameter limits it to just include the given project.” -Thus, this is not relevant to the target path name issue that you’ve reported.

Hi ,
thanks for investigation.
Obvious work-around (not using spaces) is clear, my intention was to initiate future fix. I am happy with the fact that the bug is registered.

Regarding “-ScripstForProject”, I do not mind about the approach you described, but still, it is a path name without quotes. This breaks the command line into a set of unexpected parameters, which can potentially lead to undesired behaviour.