Windows with space in path

[Mario Giammarco]

Hello,

I have a windows task with this custom command:

C:\'Program Files (x86)'\'Microsoft Visual Studio'\2019\Community\MSBuild\Current\Bin\msbuild.exe

The command has spaces in path. When I launch it in some windows 10 pcs it works correctly in others it says that x86 is wrong argument. It means it does not accept spaces in file name.

It exactly the same problem of this issue: 

https://github.com/gocd/gocd/issues/4173

There are several issues with similar problems all marked as stale.

I do not understand if someone has solved it, or there is a workaround.

Can you help me?

Thanks,

Mario

[Ashwanth Kumar]

There is a comment with a possible workaround on the linked issue - https://github.com/gocd/gocd/issues/4173#issuecomment-596109199. Have you tried that? 

We've a similar problem with linux based systems as well. As a general rule I always wrap all my commands inside a shell script (or in your case a PS file) and check it in as part of the repository like a bin/build.sh and run that from GoCD instead of manually specifying the command on GoCD. This has the following advantages like:

1. I can move away from GoCD if I ever want to - think of it like an anti-Vendor lock-in mechanism.
2. I can also build it locally or inside a docker or things like that If needed.
3. I have fine grained control over who changed what and when on the commands for the build via my Git history. GoCD also does this, but it ain't easy to view the change history. You can track these changes too as part of your code review process itself.
4. Since go-agents don't really spawn the command inside a shell that means referring to environment variables as part of the command would also be a pain. Having the command in a separate script allows me to access environment variables for my build like embedding the version as part of the build process into my final artifacts so I can track them via an internal API for example.

Thanks,

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/8e8ef90a-9f91-4b3a-b479-10a944bb1ccen%40googlegroups.com.

--

Ashwanth Kumar / ashwanthkumar.in

[Mario Giammarco]

Il giorno giovedì 24 febbraio 2022 alle 11:38:05 UTC+1 ashwant...@gmail.com ha scritto:

There is a comment with a possible workaround on the linked issue - https://github.com/gocd/gocd/issues/4173#issuecomment-596109199. Have you tried that? 

Yes infact I replied there that the workaround does not work for me 

We've a similar problem with linux based systems as well. As a general rule I always wrap all my commands inside a shell script (or in your case a PS file) and check it in as part of the repository like a bin/build.sh and run that from GoCD instead of manually specifying the command on GoCD. This has the following advantages like:

1. I can move away from GoCD if I ever want to - think of it like an anti-Vendor lock-in mechanism.
2. I can also build it locally or inside a docker or things like that If needed.
3. I have fine grained control over who changed what and when on the commands for the build via my Git history. GoCD also does this, but it ain't easy to view the change history. You can track these changes too as part of your code review process itself.
4. Since go-agents don't really spawn the command inside a shell that means referring to environment variables as part of the command would also be a pain. Having the command in a separate script allows me to access environment variables for my build like embedding the version as part of the build process into my final artifacts so I can track them via an internal API for example.

I need to consider this solution thanks for it. But I am still worried that there is no simple escape sequence and also the result depends on which machine I run on it. 

[Mario Giammarco]

I was able to make it work putting in custom command this line:

powershell -command Invoke-Expression \"& 'c:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\amd64\msbuild.exe'\"

Please note escape "\" on double quotes.

This is my workaround.

I still do not understand why on some pc the agent has no problems running this custom command:

c:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\amd64\msbuild.exe

Without quotes or other problems.

In other windows pc I need to use powershell.

In this case the double quotes are "eaten" somewhere but escaping them works.