update-golang: Minimal-Intrusion Go Installation Script

Why update-golang Exists

update-golang addresses a narrow administrative task: installing a new Go release without requiring the Go toolchain to be managed through a Linux distribution package. It is written primarily as a Shell script and is intended for administrators or users who want to place Go at the distribution-independent location used by the official installation instructions.

The project's defining choice is where it installs files. The default destination is /usr/local/go, while /usr/local/go/bin is added to PATH through /etc/profile.d/golang_path.sh. That arrangement affects every user who receives the system-wide shell setting. It also keeps the script focused on extracting an official binary distribution rather than introducing an additional package manager or runtime dependency.

The script is aimed at Unix-like systems whose OS and architecture can be detected by its Shell logic. The README explicitly documents a Linux example and provides an OS override, but it does not present a complete support matrix for macOS, BSD variants, Windows or other platforms. That makes the project more relevant to a system administrator comfortable with Linux filesystem conventions than to a developer seeking a cross-platform GUI installer.

Release Selection and Download Flow

The default flow starts by searching for the latest binary release listed at https://go.dev/dl/. According to the README, the script excludes beta releases and release candidates during normal detection. A particular non-final release can be requested through the RELEASE environment variable, with 1.11rc1 given as the example.

After determining the release, the script derives the operating system and architecture from local system values. It then downloads the corresponding archive from the configured SOURCE location. The repository's example points SOURCE at https://storage.googleapis.com/golang, while the customization list exposes that value as an environment variable. This separation matters for readers evaluating where archives come from: changing SOURCE also changes the source from which the script expects to obtain a release.

The README describes the downloaded archive as a cache under /usr/local by default. Reusing a cached file can avoid another download, while the -declutter option prevents caching. Once selected, the archive is extracted so that the release is installed at /usr/local/go. The script also cleans up an older link when it finds one, updates the profile file, and performs installation checks documented in the sample output.

PATH, GOROOT and System Changes

The installer changes shell configuration separately from the Go archive extraction. By default it writes /usr/local/go/bin to /etc/profile.d/golang_path.sh. The same profile file can be used to set GOROOT when that value is needed. The README states that the script does not modify GOPATH automatically.

This approach has a clear benefit for a conventional system-wide installation: users receive a fixed executable location without editing each user's shell configuration manually. It also creates a visible administrative artifact. An operator can inspect /etc/profile.d/golang_path.sh to determine what PATH and GOROOT settings have been applied.

The profile file is rewritten through the script's path-management logic, with old settings removed before new settings are issued. That behavior is convenient for repeat runs, but it means the profile file is part of the installation's state. A system with existing custom Go settings should inspect that file before running the script. The README does not document a dry-run mode, a backup filename, or a selective merge policy for unrelated profile content.

Install and First Go Check

The README's basic workflow clones the repository, changes into its directory and runs the installer with sudo. Before execution, it recommends downloading the SHA256 checksum file and verifying the script with sha256sum. The expected result in the README is an OK line for update-golang.sh.

The commands below are copied from the README. The checksum command should be run before granting the script root privileges. A reader should see the script itself reported as verified.

wget -qO hash.txt https://raw.githubusercontent.com/udhos/update-golang/master/update-golang.sh.sha256
sha256sum -c hash.txt

After verification, clone and install the project with the documented commands. Running the script as root is required for the default /usr/local/go and /etc/profile.d/golang_path.sh locations.

git clone https://github.com/udhos/update-golang
cd update-golang
sudo ./update-golang.sh

The sample session shows the script reporting the selected release, cache path, architecture, install destination and profile file. It then reports a successful `go version` check and a temporary hello-world program run. The README's sample output uses an older Go release, so the exact version displayed will depend on the release selected at execution time.

Per-User Installation and Removal

The script supports a per-user installation by changing DESTINATION and PROFILED. The README's example creates ~/golang, installs there, and writes PATH-related settings to ~/.bash_profile. This path avoids the default global installation and does not require sudo according to the documented example.

The commands are intentionally short because the environment variables define the installation scope. The reader should see the release installed below the user's home directory rather than at /usr/local/go.

mkdir ~/golang
DESTINATION=~/golang PROFILED=~/.bash_profile ./update-golang.sh

Removal depends on how the installation was configured. The default installation has a documented remove option, while a per-user removal must repeat the same DESTINATION and PROFILED values used during installation. That requirement is operationally significant. A removal command without matching variables may not target the same profile file or destination.

sudo ./update-golang.sh remove

For the per-user example, use the same path variables with `remove`:

DESTINATION=~/golang PROFILED=~/.bash_profile ./update-golang.sh remove

The README does not describe transactional rollback, version retention, or automatic recovery if extraction fails midway.

Customization Boundaries and Failure Risks

The script exposes several variables for adapting its behavior: RELEASE_LIST, SOURCE, DESTINATION, RELEASE, OS, ARCH_PROBE, ARCH, PROFILED, CACHE, GOPATH and DEBUG. This is useful when the defaults do not match a host, but it also means the operator must understand the relationship between them. For example, changing DESTINATION changes the install location, while changing PROFILED changes the shell profile that receives PATH-related settings.

The README documents forcing a release candidate with RELEASE=1.11rc1 and forcing beta, prerelease or architecture values through the corresponding variables. It does not document validation for arbitrary combinations of OS, ARCH and release archives. A forced value that does not match an available artifact can therefore produce a download or installation failure.

The -declutter option avoids retaining downloaded archives. Without it, archives remain under CACHE, which can consume disk space until manually erased. Cache reuse may also make the timing of an update less obvious from the filesystem alone. The script's install test is useful, but it is not a substitute for checking the release archive against an independently obtained checksum.

Comparison With Manual Go Installation

The actual alternative described by the project is manual installation based on the official instructions at https://go.dev/doc/install. The manual approach gives the administrator direct control over which release page is consulted, which archive is downloaded, which checksum is verified and where the archive is extracted. It does not automatically add the repository's profile file or reuse the repository's cache logic.

update-golang is different in operation, not merely in presentation. It automates release discovery, OS and architecture selection, archive caching, extraction, PATH configuration and post-install checks. That automation is useful for repeated administration, but the trade-off is that the script performs privileged filesystem and profile changes after the user executes one command. Reviewing update-golang.sh is therefore more important than treating the README's short command as the entire installation process.

The repository also uses GitHub Actions-era CI files and shell checks in its layout, including shellcheck.sh and a checksum update script. Those files indicate repository maintenance tooling, but the README does not explain their exact CI guarantees. A prospective user should inspect them separately rather than infer a formal upgrade process from their presence.

Maintenance Signals and MIT Licensing

The repository is not archived, and its last push was on 2026-08-28. The listed releases are v0.24 from 2022-03-13, v0.23 from 2021-02-28 and v0.22 from 2019-09-17. The release list therefore does not establish a current version cadence, although the last push is a repository activity fact.

The project uses the MIT license. That license permits use, copying, modification, distribution and sublicensing subject to its terms, while preserving the copyright and license notice. This is a licensing summary, not legal advice. Because the project is a small Shell installer, its upgrade cost is likely to involve reviewing changes to update-golang.sh, the checksum file and any CI configuration rather than compiling a new binary. The README does not document a release upgrade command or compatibility policy between versions.

The most concrete verification points are the script checksum, the selected release, the SOURCE URL, the installation destination and the profile file path. Those controls determine both what code runs and what the host changes.

Editorial conclusion

Administrators who already follow the official Go installation locations and accept scripted changes to /usr/local and /etc/profile.d can consider update-golang after verifying the script checksum and reviewing its configurable paths. Users who need package-manager integration, rollback automation, or broad platform support should first confirm that its direct installation model meets those needs; its stated MIT license permits reuse and modification, while its last push was on 2026-08-28.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. udhos/update-golang on GitHub