I'm very new to system programming.
I have a Go program which uses net/http and starts an http server.
When I build a Windows binary and tried on a target Windows machine, nothing worked except Printfs before it starts the server.
As soon as I installed Go on the target Windows machine, everything started working!
Here is my program:
package main
import (
"fmt"
"log"
"os/exec"
"net/http"
)
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hi there #%s!", r.URL.Path[1:])
}
func main() {
path, err := exec.LookPath("go")
if err != nil {
log.Fatal("Go is not your fortune :|")
}
fmt.Printf("Go is available at %s\n", path)
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}
If go doesn't build all the dependencies with its program then how do I do it? If it does, why it is not working?
Does target systems have to have go installed prior to run any Go programs?
Please help! Thanks.
Your app doesn't work without Go because you call log.Fatal() if it doesn't find the go tool, and log.Fatal() terminates your app:
Fatal is equivalent to Print() followed by a call to os.Exit(1).
Your executable binary will contain everything it needs if you build it from the source you posted either with go build or go install (see What does go build build? for details). Just don't call log.Fatal() and it should work.
And on a side note: you should check and print errors returned by http.ListenAndServe(), e.g.:
panic(http.ListenAndServe(":8080", nil))
Because if this fails, you won't know why it doesn't work (e.g. you already started the app and the port is taken / in use).
No, the target system does not have to have the Go compiler installed for the executable compiled with Go to run. You can compile your program with go install or go build on one Windows computer, copy it to another one where Go is not installed and run it there.
Make sure the program that you compile starts with the package main statement - otherwise only a library file will be compiled.
Make sure to check whether the user that runs your program has rights to listen on the port that the http server uses. The ports 0-1023 - "Well Known Ports" - "can only be used by system (or root) processes or by programs executed by privileged users" (https://support.microsoft.com/en-us/kb/174904), so try to start your program as a privileged user (for example, Administrator) or use a non-privileged port >= 1024 (ex. http.ListenAndServe(":8080", nil) should start the server on a non-privilege port. Take a very simple example - for example from https://golang.org/doc/articles/wiki/ - and see if you can get it to work.
Related
I have a problem using GoLand's debugger for a piece of code that tries to read from the stdin. For example, the following code:
package main
import (
"io"
"os"
"strings"
)
func main() {
io.Copy(os.Stdout, strings.NewReader("Start typing now...\n"))
io.Copy(os.Stdout, os.Stdin)
}
executes perfectly when I run it from within GoLand - the console window collects the input properly. But when I use the debug command - I can see the my input appearing in the console window, but the enter key will not end the input string, instead the cursor just moves to the next line.
My versions:
GoLand 2018.2.2
Build #GO-182.4129.57, built on August 23, 2018
JRE: 1.8.0_152-release-1248-b8 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6
As you are using OSX there is no simple way to get this working.
Assuming you are using Go 1.10 or newer, change the directory to $GOPATH/src/github.com/user/package, then compile your application using go build -gcflags "all=-N -l" github.com/user/package, and then manually start the application in Terminal manually. Once the application runs, go to Run | Attach to Process... and select the application from the list. This will attach the debugger to the running application.
Please note that the compilation step is needed in order to improve the debugging experience but you should not use the resulting binary in production as (almost) all optimizations have been turned off.
I am new Shogun user,besides, this is my first time to use SVN.(I think the problem is SVN not Shogun)
those are the environment what I use:
Windows 10
Shogun 4.0.0
TortoiseSVN-1.9.3.27038-x64-svn-1.9.3;
VisualSVN-5.1.3;
VisualSVN-Server-3.5.1-x64;
VS 2013
Now I am in trouble when I want to get started an simple example of Shogun(copy in Documentation) as follow:
#include <shogun/base/init.h>
using namespace shogun;
int main(int argc, char** argv)
{
init_shogun();
exit_shogun();
return 0;
}
then, I try to compile it in Vs 2013, it tell me:
1> Generating version header
3> Building Custom Rule E:/shogun/CMakeLists.txt
3> CMake does not need to re-run because E:\shogun-configure\CMakeFiles\generate.stamp is up-to-date.
3> Creating directories for 'MSIntTypes'
3> Performing download step (SVN checkout) for 'MSIntTypes'
3> svn: E170013: Unable to connect to a repository at URL ' http://msinttypes.googlecode.com/svn/trunk '
3> svn: E175012: Connection timed out
3> C:\ProgramFiles(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006:
"cmd.exe" has exited. code is 1.
Then, I considerd that maybe some problems with SVN, I try to checkout some respositories:
At first, I try to checkout an respositories what I create myself:'_http://burningbear:8443/!/#new_rep', it can be checkout normally.
Then I try to chekout the respository:'_http ://msinttypes.googlecode.com/svn/trunk', but the Tortoise just not responding for a long time, then it reply me that:
Command: Checkout from _http://msinttypes.googlecode.com/svn/trunk, revision HEAD, Fully recursive, Externals included
Error: Unable to connect to a repository at URL
Error: '_http://msinttypes.googlecode.com/svn/trunk'
Error: Error running context: 你的主机中的软件中止了一个已建立的连接。(what I use is Chinese,it means "the software in your host stop an connected connection")
In China, We can not access googlecode unless we use VPN, so I change the server, to enable Proxy Server, the following is my setting:
Server address: 127.0.0.1
Port: 8087
Then I try to checkout again as:
When I check out _http://msinttypes.googlecode.com/svn/trunk
Checkout from _http://msinttypes.googlecode.com/svn/trunk, revision HEAD, Fully recursive, Externals included
Unable to connect to a repository at URL'_http://msinttypes.googlecode.com/svn/trunk'
The HTTP method 'OPTIONS' is not allowed on '/svn/trunk'
When I update the repositories what I have checkout before(URL is :_http://burningbear:8443/!/#new_rep). It move slowly, I spend about half hour, SVN tell me: "2 kBytes transferred in 20 minutes and 2 seconds"
Command: Update
Updating: E:\test2
Error: Unable to connect to a repository at URL 'https://burningbear:8443/svn/new_rep'
Error: Connection timed out
Completed!:
Now, I don't know what's the problem. It take me several days and I still can not solve it. Please help me! Thank you in advanced!
(I can not post more than 2 links now, so all of URL above I add an '_' mark before 'http')
Currently there's no way to compile natively shogun on Windows unfortunately. Although your problem seems to be unrelated, and it fails with svn, which is weird because the official repo of the shogun is using git: http://github.com/shogun-toolbox/shogun/
worked on the weekend on the native Windows support of shogun, you can find it in the feature/windows branch of the official repository: https://github.com/shogun-toolbox/shogun/tree/feature/windows
UPDATE: the feature branch has been merged into develop branch. from now on shogun can be compiled on windows natively.
Google Code is not available anymore: http://msinttypes.googlecode.com/svn/trunk. That's why the tool fails to access googlecode.com.
I created an application that I want to run invisibly in the background (no console). How do I do this?
(This is for Windows, tested on Windows 7 Pro 64 bit)
The documentation found online says I can compile with something along the lines of,
go build -ldflags -Hwindowsgui filename.go
But this gives an error: unknown flag -Hwindowsgui
With more recent (1.1?) versions of the compiler, this should work:
go build -ldflags -H=windowsgui filename.go
When I continued searching around I found a note that the official documentation should be updated soon, but in the meantime there are a lot of older-style example answers out there that error.
Using Go Version 1.4.2
go build -ldflags "-H windowsgui"
From the Go docs:
go build [-o output] [-i] [build flags] [packages]
-ldflags 'flag list' arguments to pass on each 5l, 6l, or 8l linker invocation.
go build documentation
ldflags docs
If you don't want to type the long build instructions every time during debugging but still want the console window to disappear, you can add this code at the start of your main function:
package main
import "github.com/gonutz/w32/v2"
func main() {
console := w32.GetConsoleWindow()
if console != 0 {
_, consoleProcID := w32.GetWindowThreadProcessId(console)
if w32.GetCurrentProcessId() == consoleProcID {
w32.ShowWindowAsync(console, w32.SW_HIDE)
}
}
}
Now you can compile with go build. Your program will show the console window for a short moment on start-up and then immediately hide it.
I need some Powershell advice.
I need to install an application's MSP update file on multiple Win08r2 servers. If I run these commands locally, within the target machine's PS window, it does exactly what I want it to:
$command = 'msiexec.exe /p "c:\test\My Application Update 01.msp" REBOOTPROMPT=S /qb!'
invoke-wmimethod -path win32_process -name create -argumentlist $command
The file being executed is located on the target machine
If I remotely connect to the machine, and execute the two commands, it opens two x64 msiexec.exe process, and one msiexec.exe *32 process, and just sits there.
If I restart the server, it doesn't show that the update was installed, so I don't think it's a timing thing.
I've tried creating and remotely executing a PS1 file with the two lines, but that seems to do the same thing.
If anyone has advice on getting my MSP update installed remotely, I'd be all ears.
I think I've included all the information I have, but if something is missing, please ask questions, and I'll fill in any blanks.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
My process for this is:
Read a CSV for server name and Administrator password
Create a credential with the password
Create a new session using the machine name and credential
Create a temporary folder to hold my update MSP file
Call a PS1 file that downloads the update file to the target server
>>> Creates a new System.Net.WebClient object
>>> Uses that web client object to download from the source to the location on the target server
Call another PS1 file that applies the patch that was just downloaded –>> This is where I’m having issues.
>>> Set the variable shown above
>>> Execute the file specified in the variable
Close the session to the target server
Move to the next server in the CSV…
If I open a PS window and manually set the variable, then execute it (as shown above in the two lines of code), it works fine. If I create a PS1 file on the target server, containing the same two lines of code, then right click > ‘Run With PowerShell’ it works as expected / desired. If I remotely execute my code in PowerGUI, it returns a block of text that looks like this, then just sits there. RDP’d into the server, the installer never launches. My understanding of the “Return Value” value is that “0″ means the command was successful.
PSComputerName : xx.xx.xx.xx
RunspaceId : bf6f4a39-2338-4996-b75b-bjf5ef01ecaa
PSShowComputerName : True
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 2
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ProcessId : 4808
ReturnValue : 0
I even added a line of code between the variable and the execution that creates a text file on the desktop, just to verify I was getting into my ‘executeFile’ file, and that text file does get created. It seems that it’s just not remotely executing my MSP.
Thank you in advance for your assistance!
Catt11.
Here's the strategy I used to embed an msp into a powershell script. It works perfectly for me.
$file = "z:\software\AcrobatUpdate.msp"
$silentArgs = "/passive"
$additionalInstallArgs = ""
Write-Debug "Running msiexec.exe /update $file $silentArgs"
$msiArgs = "/update `"$file`""
$msiArgs = "$msiArgs $silentArgs $additionalInstallArgs"
Start-Process -FilePath msiexec -ArgumentList $msiArgs -Wait
You probably don't need to use the variables if you don't want to, you could hardcode the values. I have this set up as a function to which I pass those arguments, but if this is more of a one-shot deal, it might be easier to hard-code the values.
Hope that helps!
using Start-Process for MSP package is not a good practice because some update package lockdown powershell libs and so you must use WMI call
I wrote this simple prototype client to send commands to a server I'm developing. It works perfectly running in GHCi, but the compiled version buffers everything typed in until I type in "quit" and the program exits. At that point all the input text gets sent.
What am I doing wrong? And why is it different when compiled?
Update: it does work as expected if compiled with ghc Main.hs. The problem happens when compiled with Leksah via Package -> Build. Anyone know how to get the command line Leksah is using?
System info: OSX 10.6, GHC 7.0.3, network 2.3.0.2
module Main (
main
) where
import System.IO
import Network
main = do
hServer <- connectTo "localhost" (PortNumber 7000)
hSetBuffering hServer NoBuffering
loop hServer
hClose hServer
where loop :: Handle -> IO ()
loop hServer = do
s <- getLine
hPutStrLn hServer s
case s of "quit" -> return ()
otherwise -> loop hServer
Leksah uses "cabal build", older versions "runhaskell Setup build".
Hmm, it seems Leksah wasn't actually building the app when I thought it was. I must have been running old code without the hSetBuffering call. A clean & rebuild has sorted it out. Apologies and thanks to everyone for your time and help.
edit: Found it - in case anyone else gets confused by this, when package->build is clicked, Leksah does not generate a compiled app if it's in debug/ghci mode.