Fix symlink creation when resulting command has spaces #286
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Go version used for the repository development could not be found
so the latest installation available was used. In doing so, some compile
time errors appeared with regards to filepath and the Unzip function
that had to be corrected.
The Go exec module wraps the os.StartProcess functionality. The initial
argument escaping appears to be correct, however, during the pipe
writing when actually starting the process the command is escaped again
in quotations making the command invalid. This makes the command fail
and no symlink is created.
This was verified by printing the resulting argument string by utilizing
the same logic that makes the command line argument and escapes it. As
this appears to be a Go library issue, a different tactic was attempted.
In case of this failure, a backup mechanism has been put in place to
use the os module to create the symlink directly.
After much deliberation it was decided this backup mechanism should only
be attempted when the initial attempt fails. The reasoning behind this
is because the initial command request attempts to elevate the command
which would give access to create the symbolic link in "Program Files",
which is otherwise a protected folder. The os call could fail here due
to insufficient permissions.
Potentially fixes: #281, #266, #30