release: after installing via MSI installer, prompt says "go is not a recognized command" #18680

rakyll · 2017-01-17T04:52:10Z

Fresh install Go on Windows via the the MSI installer (version: go1.8rc1).
After installation is complete, start a new command prompt.
Type go into the prompt.

Actual result:

"go" is not recognized as an internal or external command, operable program or batch file.

Expected result:
The go binary is found.

The text was updated successfully, but these errors were encountered:

minux · 2017-01-17T04:59:35Z

Does the go installer modify the system %PATH%? What's the system %PATH% after installation? From the source code, it does look like it should modify the system %PATH%. https://github.com/golang/build/blob/master/cmd/release/releaselet.go#L647

alexbrainman · 2017-01-17T05:21:24Z

"go" is not recognized as an internal or external command, operable program or batch file.

I cannot reproduce it. It does work for me. I am running Windows 7.

Perhaps something is not quite right with your step 2.
https://blogs.msdn.microsoft.com/oldnewthing/20150915-00/?p=91591/ for the background.

Does the go installer modify the system %PATH%?

It does modify mine.

Alex

as · 2017-01-17T05:45:51Z

How was the new command prompt started? On most systems I've noticed running CMD.exe in the existing console doesn't work. It has to be a new window.

rakyll · 2017-01-17T19:20:13Z

I am able to produce it on 32-bit Windows 8 and 10.

My %PATH% is not modified.

I am opening a new command prompt window via a right click on the Start button.

broady · 2017-01-17T20:55:21Z

Couldn't reproduce on a fresh VM (Windows Server 2016 Datacenter - version 1607, OS version 14393.693).

Also couldn't reproduce on a 64-bit Windows 10. Could be specific to 32-bit?

Related to #17602 perhaps?

rakyll · 2017-01-18T04:09:49Z

I used

msiexec /l*v install.log /i C:\Users\jbd\Downloads\go18rc.windows-386.msi

to gather logs but installation succeed (at my third retry) and added GOROOT and modified the GOPATH. I don't understand what makes this inconsistently fail.

I haven't updated the installation path, I am not thinking it might be related to #17602.

alexbrainman · 2017-01-18T05:35:02Z

and modified the GOPATH

Go installer does not add GOPATH variable. Did you mean it modified PATH?

Alex

alexbrainman · 2017-01-18T05:47:51Z

I am able to produce it on 32-bit Windows 8 and 10.

Are you sure you have 32-bit Windows. What does "echo %PROCESSOR_ARCHITECTURE%" prints? 32-bit Windows is not common now days.

I tried installing 32-bit version of Go on 64-bit version of Windows, and that works for me.

Alex

bradfitz · 2017-01-24T20:58:00Z

There is only today or tomorrow to get a change submitted for Go 1.8.

This won't block the release.

johnsonj · 2017-01-25T00:38:33Z

No repro on a fresh 32-bit Server 2008 Datacenter VM for Go1.8rc2

rakyll · 2017-01-25T07:38:57Z

Closing this until reproduced. It is clear that it is not making to 1.8 if the bug is there.

as · 2017-01-26T22:25:01Z

I'm able to reproduce this on W10 amd64, the details are in the session below.


C:\Users\as>ver & set | findstr -i arch

Microsoft Windows [Version 10.0.14393]
PROCESSOR_ARCHITECTURE=AMD64

C:\Users\as> call "C:\Users\as\Downloads\go1.8rc3.windows-amd64.msi"

#
# After install, opened a new cmd window from the run bar
#

C:\Users\as>go
'go' is not recognized as an internal or external command,
operable program or batch file.

#
# Installed git before go msi (no reboot), but its in the %path%
# Go is not.

C:\Users\as>echo %path% | findstr -i git
C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Git\cmd;C:\Users\as\AppData\Local\Microsoft\WindowsApps;

C:\Users\as>echo %path% | findstr -i go

#
# Check weird GUI thing for updated path environment variable
# Not in path here either
C:\Users\as>sysdm.cpl

#
# Check registry
# C:\Go\bin is here, as the last element

C:\Users\as>reg query "HKLM\System\CurrentControlSet\Control\Session Manager\Environment" | findstr -i go
    Path    REG_SZ    C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Git\cmd;C:\Go\bin
    GOROOT    REG_SZ    C:\Go\

The registry, as shown above, contains the updated PATH. So the MSI did in fact do its job. So then why did the path not get updated in a new command prompt? It depends on how the installer itself was started. Here's my interpretation of what happens:

The update to the system environment variables is reflected in the registry, as well as the environment of the process.

When you double click the MSI, it executes in the same environment as the desktop process (explorer). The changes to the path happen in the same environment as the desktop, the subsequent command prompts created by the desktop receive a copy of this updated environment, so PATH, and everything else works as intended.

When the MSI is run from the command prompt, it receives only a copy of cmd's environment. So when it changes the PATH value, the change only exists for that copy of the environment and is never shared with explorer. New command prompts started from explorer use the old path, because explorer's environment remains the same. Logging out, restarting, or just killing explorer and restarting it fixes the issue because explorer reads the registry when it initializes.

The following can test this idea:

Install the MSI from the command prompt
Open a new cmd and run the go command (expect fail)
Create a new desktop process and run cmd from it
explorer C:\windows\system32\cmd.exe
Try the go command now (this worked on my system)

johnsonj · 2017-01-26T22:33:12Z

@as does it repro when you open a new command line? it needs to run from explorer.exe, so Start > Run > cmd.exe > Go.

It's in your registry Path so it should be picked up by a fresh environment.

as · 2017-01-27T00:28:35Z

@johnsonj

Yes, until explorer was restarted, even using "Start > Run" failed to find the go program. I've edited the previous comment with more details.

johnsonj · 2017-01-27T03:36:36Z

Thanks for the detailed repro! I tested mine via double click (instead of msiexec as @rakyll and @as mentioned)

Perhaps cli needs an explicit WM_SETTINGCHANGE as mentioned in nodejs/node#613 MSDN

As @as pointed out with the reg query- we're setting the right upstream value, it's just not propagating to existing processes.

johnsonj · 2017-01-27T03:48:27Z

@rakyll maybe re-open and tag for Go1.9?

johnsonj · 2017-02-06T05:04:31Z

I believe this is the issue. It's a reasonable explanation of why it doesn't repro in all environments/consistently:

Windows Installer itself sends the WM_SETTINGCHANGE message for settings it changes while processing an MSI package but cannot do so for changes a package makes via custom action. Also, Windows Installer does not send WM_SETTINGCHANGE for environment variable changes when a reboot is pending. src

CL inbound

gopherbot · 2017-02-06T15:41:12Z

CL https://golang.org/cl/36324 mentions this issue.

broady · 2017-02-16T18:52:30Z

Our version of Wix doesn't include this flag. We'll need to update it.

johnsonj · 2017-02-16T18:56:59Z

@broady I was worried about that! Is the install built by the build bots or somewhere else?

broady · 2017-02-16T18:58:44Z

Yeah, by the build bots. I just sent a change to revert it for the 1.8 release (today), but if you can see a straightforward fix, that'd be good.

gopherbot · 2017-02-16T19:01:29Z

CL https://golang.org/cl/37135 mentions this issue.

johnsonj · 2017-02-16T19:02:33Z

Wix needs to be >= v3.10.0.1519 and looks like we're at 3.5.

With a release today, rollback seems appropriate.

Can you link me to the buildbot output where this failed so I can check it out next time?

…Win" This reverts commit 924bb6b. https://golang.org/cl/36324 When running the release builds, we get this error: C:\workdir\windows\installer.wxs(155) : error LGHT0094 : Unresolved reference to symbol 'CustomAction:WixBroadcastEnvironmentChange' in section 'Product:*'. The wix documentation indicates we need to enable it: http://wixtoolset.org/documentation/manual/v3/customactions/wixsettingchange.html In any case, reverting this change for the 1.8 release. Updates golang/go#18680. Change-Id: I86e8d82dc57e585c11846edf589c4bab84a60308 Reviewed-on: https://go-review.googlesource.com/37135 Reviewed-by: Jeff Johnson <[email protected]> Reviewed-by: Chris Broadfoot <[email protected]>

bradfitz · 2017-06-15T01:16:29Z

@broady, can you handle updating our Wix, or do you need help?

gopherbot · 2017-06-22T16:20:22Z

CL https://golang.org/cl/46458 mentions this issue.

minux added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 17, 2017

minux added this to the Go1.8 milestone Jan 17, 2017

bradfitz modified the milestones: Go1.8Maybe, Go1.8 Jan 24, 2017

rakyll closed this as completed Jan 25, 2017

rakyll reopened this Feb 1, 2017

rakyll modified the milestones: Go1.9, Go1.8Maybe Feb 1, 2017

rakyll added the OS-Windows label Feb 1, 2017

gopherbot closed this as completed in golang/build@924bb6b Feb 7, 2017

broady reopened this Feb 16, 2017

gopherbot closed this as completed in golang/build@fb385a2 Jun 22, 2017

golang locked and limited conversation to collaborators Jun 22, 2018

gopherbot added the FrozenDueToAge label Jun 22, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

release: after installing via MSI installer, prompt says "go is not a recognized command" #18680

release: after installing via MSI installer, prompt says "go is not a recognized command" #18680

rakyll commented Jan 17, 2017

minux commented Jan 17, 2017 via email

alexbrainman commented Jan 17, 2017

as commented Jan 17, 2017

rakyll commented Jan 17, 2017

broady commented Jan 17, 2017

rakyll commented Jan 18, 2017

alexbrainman commented Jan 18, 2017

alexbrainman commented Jan 18, 2017

bradfitz commented Jan 24, 2017

johnsonj commented Jan 25, 2017

rakyll commented Jan 25, 2017

as commented Jan 26, 2017 •

edited

Loading

johnsonj commented Jan 26, 2017 •

edited

Loading

as commented Jan 27, 2017

johnsonj commented Jan 27, 2017 •

edited

Loading

johnsonj commented Jan 27, 2017

johnsonj commented Feb 6, 2017

gopherbot commented Feb 6, 2017

broady commented Feb 16, 2017

johnsonj commented Feb 16, 2017

broady commented Feb 16, 2017

gopherbot commented Feb 16, 2017

johnsonj commented Feb 16, 2017 •

edited

Loading

bradfitz commented Jun 15, 2017

gopherbot commented Jun 22, 2017

release: after installing via MSI installer, prompt says "go is not a recognized command" #18680

release: after installing via MSI installer, prompt says "go is not a recognized command" #18680

Comments

rakyll commented Jan 17, 2017

minux commented Jan 17, 2017 via email

alexbrainman commented Jan 17, 2017

as commented Jan 17, 2017

rakyll commented Jan 17, 2017

broady commented Jan 17, 2017

rakyll commented Jan 18, 2017

alexbrainman commented Jan 18, 2017

alexbrainman commented Jan 18, 2017

bradfitz commented Jan 24, 2017

johnsonj commented Jan 25, 2017

rakyll commented Jan 25, 2017

as commented Jan 26, 2017 • edited Loading

johnsonj commented Jan 26, 2017 • edited Loading

as commented Jan 27, 2017

johnsonj commented Jan 27, 2017 • edited Loading

johnsonj commented Jan 27, 2017

johnsonj commented Feb 6, 2017

gopherbot commented Feb 6, 2017

broady commented Feb 16, 2017

johnsonj commented Feb 16, 2017

broady commented Feb 16, 2017

gopherbot commented Feb 16, 2017

johnsonj commented Feb 16, 2017 • edited Loading

bradfitz commented Jun 15, 2017

gopherbot commented Jun 22, 2017

as commented Jan 26, 2017 •

edited

Loading

johnsonj commented Jan 26, 2017 •

edited

Loading

johnsonj commented Jan 27, 2017 •

edited

Loading

johnsonj commented Feb 16, 2017 •

edited

Loading