How can i execute my sc command through exec.Command?
Code:
cmd := exec.Command("cmd.exe", "sc", "create", "Simpler", "binpath="+os.Getenv("APPDATA")+"\\Simpler\\cc.exe", "displayname=MY SERVICE");
cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true};
out, _ := cmd.Output(); fmt.Println(string(out))
This i get in command prompt (open command prompt in current command prompt -_-):
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>cd c:\prog\logs
c:\prog\logs>go build test.go
c:\prog\logs>test.exe
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
c:\prog\logs>
c:\prog\logs>
Followed command cannot be executed. I do not get anything! Where is the problem?
Command been started if i execute sc.exe in current command prompt but not started if i execute in new command prompt.
That is if i remove first argument "cmd.exe" my program succesfully execute with excepted result. But how to execute in a new window?
Well, the immediate problem is that what you do is not how
cmd.exeshould be told to execute an external command—in order to make it execute one, you should passcmd.exeeither the/Cor/Kcommand-line option, like inWhat you observe with your call is that
cmd.exeignores the rest of the arguments you pass to it and just runs—that's exactly what you're observing.Start with studying the output of
cmd.exe /?and the built-in Windows help system to get better idea of how it works.The next problem is that there is absolutely no reason to make
cmd.exeinvolved in runningsc—just runscdirectly rather than jumping aroundcmd.exeto make it executesc.The next problem is that you're ignoring the error value returned by the call to
os/exec.Cmd.Output. Since Go (luckily) does not have exceptions, handing all error values is of paramount importance—it's better to ignore everything else but not errors. If you're writing highly-experimental code, you might start with a dumb helper likeand then roll like
This approach is not for production-grade code, but allows for faster code churn when experimenting.
You might also consider calling directly into Win32 API to manage services as it will make error handling substantially easier.