As a total work-around you can always write start_chrome.bat:: your command to launch chrome.
and then from go execute as: "cmd.exe", "/k", "start_chrome.bat" (double-check the "/k", I'm writing from memory). Also, to me the red flag is using -foo="quoted argument".parts. On windows, cmd-line args are just a single string (see https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw) and the standard for quoting arguments is informal. So Go encodes []string{arg1, arg2, ...} as a single string in what they believe is the right way and chrome decodes this back into separate arguments the way it believes is the right way. If there's a mismatch, problems ensue. For that reason, if chrome accepts it, use []string(`-foo`, `arg with space`} instead of []string{`-foo="arg with space"`}.. Double-quoting of `"` is most likely the reason for the mismatch. In the end, you don't have to guess. Go's implementation of os/exec is a wrapper around windows API for creating processes https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw That implementation is shipped with the compiler. You can step through this code in the debugger down to the point of calling said windows API. You can see exactly what Go is passing as cmd-line arg and you can then test with chrome what the right form would be. You'll either notice that you made a mistake in how you're calling it or that there is a bug in the implementation. If there's a bug in the implementation, you can open an issue on GitHub and you can fix the bug yourself by copying the implementation and making a fix. That being said, to reiterate, the quoting of args i.e. constructing a single string out of multiple args and then parsing it back into parts is not formally specified and even if it was, different implementations can have bugs. It could just as well be issue on the chrome side. -- kjk On Thursday, March 21, 2019 at 9:13:52 AM UTC-7, XXX ZZZ wrote: > > Hello, > > I'm trying to launch Chrome from Go under windows, some of the arguments > I'm passing have custom paths in it and it seems that go is sanitizing > these arguments and not recognizing the paths. Basically it seems to be > appending the application path into the arguments with a path. > > Code is as follows: > > package main > > import( > "os/exec" > "fmt" > ) > > func main(){ > fmt.Printf("Trying to start Chrome\n") > > > AppCommand:="C:\\Users\\User\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe" > Args:=[]string{" --user-data-dir=\"C:\\ProfileTest 1\"", > " --load-extension=\"C:\\test\"", > " --disk-cache-dir=\"C:\\profileCache\"", > " --disable-preconnect", > " --dns-prefetch-disable", > " --start-maximized", > " --allow-insecure-localhost", > " --ignore-certificate-errors", > " --ignore-certificate-errors-spki-list", > " --no-default-browser-check", > " --disable-infobars"} > > cmd := exec.Command(AppCommand, Args...) > //stdout, err := cmd.Output() > if err := cmd.Start(); err != nil { > fmt.Printf("Start Chrome error %+v\n", err) > continue > } > } > > At chrome, we noticed that the load-extension path is being appended with: > "C:\\Users\\User\\AppData\\Local\\Google\\Chrome\\Application\\" so it ends > up with: > "C:\\Users\\User\\AppData\\Local\\Google\\Chrome\\Application\\""C:\\test", > same goes for the other arguments with a path. > > Is there any way to tell go to avoid doing this? Maybe just executing a > command straight from a command line? > > Thanks. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
